[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Alejandro Colomar]

Hi Sid, Paul,

On Tue, Oct 22, 2024 at 03:05:49PM GMT, Siddhesh Poyarekar wrote:
> 
> 
> 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
> :/

I plan to make it defined again in C2y.  I'll prepare a paper for
standardizing on the BSD/Unix V7 semantics, but I'll do that after glibc
has changed.  Bionic changing would also be an interesting thing.


But yes, I think it's too much machinery.  In reality you don't need to
make anything configurable.  Just changing the behavior tonight wouldn't
break stuff.  At most a few 0B leaks here and there.  Most code will in
fact be more stable, since people are already testing for p==NULL after
realloc, not p==NULL&&errno, so most programs are actually not well
written for glibc (see my example program in the response to Florian).

And it is perfectly possible to write code that works well under both
the new and the old semantics, so it doesn't make sense to provide a
feature test macro.  Just tell people to program for both behaviors, by
testing (p == NULL && errno) for failure.  That errno check will become
dead code under the new behavior, and in a decade when the new behavior
is everywhere it will be possible to remove it.

I think I wouldn't even make a new symbol, since old binaries will
probably benefit from the bugfix and get more stability for free.  But
if you want to be cautiout, a new symbol would be the only thing I'd do.


Have a lovely day!
Alex


-- 
<https://www.alejandro-colomar.es/>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20241024/22a3f6cd/attachment.sig>