Re: [RFC] Supporting malloc_usable_size

[Siddhesh Poyarekar <siddhesh@gotplt.org>]

On 2022-12-02 00:28, DJ Delorie wrote:
> Sam James <sam@gentoo.org> writes:
>> Right. It's still not clear to me if glibc is actually interested in supporting
>> the use case here. If it isn't, it should be stated clearly so it's clear
>> who is to blame when FORTIFY_SOURCE=3 complains.
> 
> I don't think it's up to glibc to support a "use case" per se.  The API
> does what is documented, no more, no less.  As long as we function
> "correctly", the users can abuse that functionality all they want.  My
> opinion is just that, when they do that, it's up to them to make sure
> their abuse plays well with other tools, like gcc and FORTIFY_SOURCE=3.
> 
> Hence my focus on documentation.
> 
> We can document what the APIs do.
> 
> We can provide a tutorial that helps people understand how the APIs work
> together in a "best practices" way.
> 
> We can list caveats that document whar be dragons.
> 
> Beyond that, caveat programmer.

Thanks, from your and Sam's comments, one thing I can be sure of is that 
I (as glibc maintainer) should not be the one suggesting hacks that add 
some measure of safety to this use since that then may get misconstrued 
as endorsement by the glibc project.  It has happened before:

https://github.com/systemd/systemd/issues/22801#issuecomment-1073962482

Besides, both Andreas and Florian pointed out ways in which such 
malloc_usable_size could be unsafe despite current definitions, so that 
is further reason to not support this use case.

On to the alternative question then; given that the interface has 
minimal utility, unnecessarily exposes internal implementation caveats 
and is prone to abuse, does it make sense to deprecate it?  If not, does 
it make sense to make the note in the man page stronger by, e.g. 
removing the "without ill effects" and discourage its use for anything 
other than diagnostics?

Thanks,
Sid