[RFC] Supporting malloc_usable_size
Siddhesh Poyarekar
siddhesh@gotplt.org
Mon Dec 5 19:04:07 GMT 2022
On 2022-12-05 13:46, Zack Weinberg via Libc-alpha wrote:
> On 2022-12-02 7:39 AM, Florian Weimer via Libc-alpha wrote:
>> * Andreas Schwab:
>>
>>> On Dez 02 2022, Siddhesh Poyarekar wrote:
>>>
>>>> However the man page starts with "Although the excess bytes can be
>>>> overwritten by the application without ill effects" and maybe that
>>>> reassurance needs to be dropped.
>>>
>>> Or perhaps amended: "until the next call to malloc/realloc/free in any
>>> thread".
>>
>> The list will never be complete because glibc can call into the malloc
>> subsystem internally
>
> How about this then? "The excess bytes, if any, are only guaranteed to
> exist until the next call to malloc/realloc/free in any thread. Note
> that almost all C library functions are allowed to use malloc internally
> for scratch space, and the list of functions that do so may change
> without notice. Only the functions documented as async-signal-safe are
> guaranteed not to use malloc internally."
DJ has also made a suggestion for this[1], which seems similar to what
you have. The only concern I have is the additional guarantee the text
appears to provide (valid till the next allocator call); I'd personally
prefer something that gives absolutely no guarantees.
Maybe one of you could volunteer to propose this to the man pages project?
Thanks,
Sid
[1] https://sourceware.org/pipermail/libc-alpha/2022-December/143701.html
More information about the Libc-alpha
mailing list