[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Siddhesh Poyarekar]

On 2024-10-21 05:34, Florian Weimer wrote:
> * Siddhesh Poyarekar:
> 
>> Allow users to select this behaviour at runtime, which should allow them
>> flexibility to have glibc realloc do the same thing that many other
>> implementations do for realloc (p, 0).  The default behaviour remains
>> unchanged for now.
> 
> What's the point of this tunable?

Sorry, I should have referenced the discussion that led to this; it's 
basically a rehash of an old discussion and given that it keeps 
resurfacing, I felt that something needed to be done to move the status 
quo somewhat:

https://inbox.sourceware.org/libc-alpha/t7low35raw7dodsie7umqbnddpm7q2eenkbv5lafesrqrisudn@zqvuq3izem6t/T/#m4367eacdcdcf1633c51bfea8cfe95fcb52dc9d6d

> Applications that depend on the new behavior enabled by the tunable are
> just buggy today.  They can't rely on the tunable setting because
> tunables are deliberately not part of the glibc interface contract.

It's unfortunately not as clear cut since the behaviour is considered 
implementation defined by C17 and earlier and many implementations 
(musl, BSD for example) have had the new behaviour, something glibc 
moved away from in 1999, apparently to comply with C9x.

C23 makes the behaviour with realloc(p, 0) undefined instead of leaving 
it implementation defined, so one stand we could take is to do the same 
and update GNU tools (and the sanitizer, etc.) to promote/enforce that. 
This patch takes the "middle" route, introducing BSD-like behaviour with 
realloc(p, 0).

I'd ideally like to do both, since it solves an immediate problem as 
well as works towards a longer term resolution, eliminating zero-sized 
allocations.

I wonder if a "fortified" realloc (and malloc) would be worthwhile for 
-std=c23 and later, where a call to malloc or realloc with 0 size aborts...

Thanks,
Sid