[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Siddhesh Poyarekar]

On 2024-10-22 14:59, Paul Eggert wrote:
> On 2024-10-22 09:52, Joseph Myers wrote:
>> it ought to be compile-time configuration for each object, not link-time
>> configuration or glibc-build-time configuration
> 
> Yes, that's what I was suggesting.
> 
> 
> On 2024-10-22 09:01, Siddhesh Poyarekar wrote:
> 
>> eallocarray just calls realloc, so I don't think it needs to be 
>> handled separately
> 
> reallocarray would need separate handling if, as Joseph suggested, 
> different compilation units want different semantics.
> 

That's too much machinery for what's essentially undefined behaviour in 
C23 :/

> On 2024-10-22 09:38, Joseph Myers wrote:
>> My understanding of the intent of POSIX (if not the normative wording) 
>> is given by the APPLICATION USAGE:
> 
> Although that's a plausible reading of the intent, POSIX's normative 
> wording directly contradicts it. And AIX 7.3 realloc(p,0) (the only one 
> I know of besides GNU and MS-Windows that returns a null pointer) 
> conforms to the normative wording: it sets errno to EINVAL, which breaks 
> the plausible intent entirely.
> 
> What a mess, huh? Things would be simpler if we simply reverted Ulrich's 
> 1999 change and went back to the BSD semantics; this would cure more 
> trouble than it'd cause.
> 

Tiny nit, it wasn't Ulrich's change:

1999-04-28  Andreas Jaeger  <aj@arthur.rhein-neckar.de>

         * malloc/malloc.c (REALLOC_ZERO_BYTES_FREES): Define it to follow
         ISO C9x and Unix98.