Re: [RFC] Supporting malloc_usable_size

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Zack Weinberg via Libc-alpha:

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

I think it's a backwards-incompatible change.  The existing manual page
documents the function as MT-Safe.

With this new policy, I don't think malloc_usable_size is useful for
anything at all, and we can just deprecate it (with a deprecation
warning message) and eventually remove it from linking (after
considering the impact on replacement malloc implementations, but I
don't think it will be problematic).

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

mq_notify and timer_create do this, I think.

Thanks,
Florian