[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