[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Alejandro Colomar]

Hi Sid,

On Mon, Oct 21, 2024 at 08:51:40AM GMT, Siddhesh Poyarekar wrote:
> 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

Not new.  Rather old.  The BSDs' behavior is the original from Unix.
It's C89 that innovated, and C17 attempted to revert, but did it in an
inconsistent way that left the language of the standard so broken, that
C23 had to give up and make it undefined.

The BSDs never changed their behavior significantly from Unix V6 and V7.

> 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.

Please do NOT eliminate zero-size allocations.  That's what ANSI C tried
to do in the first place, and they broke realloc(p,0) in their attempt.
We need 0-size allocations.  If you think you don't need them yourself,
don't use them.  I do need them.

Do NOT touch the behavior of malloc(0).
Do NOT touch the behavior of realloc(NULL, 0).
Fix the behavior of realloc(p, 0) to be just what it should have always
been.

Thanks.

Have a lovely day!
Alex

> 
> 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...

N. O.

> 
> Thanks,
> Sid

-- 
<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/20241021/6a805328/attachment.sig>