[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