Re: [RFC] Supporting malloc_usable_size

[Adhemerval Zanella Netto <adhemerval.zanella@linaro.org>]

On 07/12/22 13:34, Siddhesh Poyarekar wrote:
> On 2022-12-07 05:01, Florian Weimer wrote:
>> * Siddhesh Poyarekar:
>>
>>> On 2022-12-05 15:35, Florian Weimer via Libc-alpha wrote:
>>>> 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).
>>>
>>> We don't have consensus on deprecation unfortunately.  DJ is of the
>>> opinion that the limited use (knowing the usable size but not being
>>> able to do anything with it) may be useful enough for some programs.
>>> With that position, making it clear that the extra space is never
>>> safely usable and then just leaving it at that is probably the least
>>> worst out.
>>
>> Maybe we could add a deprecation warning just for -D_FORTIFY_SOURCE=3?
> 
> I'm all for deprecation, at least partial if not full.
> 
> Thanks,
> Sid

I tend to agree with full deprecation, systemd MALLOC_SIZEOF_SAFE is an
example of what user needs to hack around with an ill defined interface and
_FORTIFY_SOURCE=3 warning should be clear that keep it is not a gain in long 
term (besides adding even more trouble for portability).

Another possibility would to make malloc_usable_size always return the malloc
size argument (although it would add some internal metadata costs).