[RFC] Supporting malloc_usable_size

Zack Weinberg zack@owlfolio.org
Mon Dec 5 18:46:08 GMT 2022


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."

> or even spontaneously from an internal service thread

We don't have any of those now, do we?  I'm inclined to say that we 
_shouldn't_ have any of those.

zw



More information about the Libc-alpha mailing list