[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Paul Eggert]

On 2024-10-24 10:02, Joseph Myers wrote:
> the choice of obsolescence followed by undefined behavior was a
> carefully considered, reasonable conclusion in a situation where every
> choice would have adverse impacts for some (application, implementation)
> pairs, and that there is nothing new sufficient to justify revisiting this
> choice already

I assume you are writing about what C23 says, and I agree with that 
assessment. However, the crux of this discussion is elsewhere: it is 
about what future versions of glibc should do and what future C and 
POSIX standards should say. Even if we agree that the current C23 
standard should say realloc(p,0) is undefined and that the current POSIX 
should partially specify its behavior (in a way that current glibc 
doesn't always conform to!), that doesn't mean we can't improve this 
messy situation moving forward.

At bottom this is a disagreement about whether it's worth the trouble to 
clean up this mess in the obvious way. Concerns have been raised that 
having glibc behave like BSD/musl/etc. would adversely affect some 
applications that assume glibc semantics. One specific application has 
been mentioned (systemd) but on further investigation it has no problems.

I'd welcome further examples of significant real-world problems that 
would come from the proposed change. So far we haven't seen any, which 
means that so far all the hobgoblins have been imaginary.