[RFC PATCH] realloc: Make REALLOC_ZERO_BYTES_FREES into a tunable

[Alejandro Colomar]

Hi Sid,

On Thu, Oct 24, 2024 at 08:57:48AM GMT, Siddhesh Poyarekar wrote:
> On 2024-10-24 08:50, Alejandro Colomar wrote:
> > 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).
> 
> AFAICT, there are strong sustained objections to unconditionally changing
> behaviour, so that is likely not an option anymore.

The strong sustained objections to changing the standard all have one
condition:

	Change the implementations first.

This is for example the case of Robert C. Seacord and JeanHeyd Meneide.
Once we fix the implementations, the standard will be trivial to change.
The only libc implementations that have realloc(p,0) and realloc(NULL,0)
be inconsistent are glibc, Win32, and Bionic, AFAIK.  Then there are
also some interposed libraries that behave like glibc for compatiblity,
but I expect them to follow glibc.  I'm already in talks with Bionic.
Once majority of implementations are fixed, I think we can force Win32
to just follow; in any case, let's ignore Win32 for now.

So, this is still an option.


Regarding the objections to changing glibc, I think it's mainly you.
I have seen a lot of FUD about introducing security vulnerabilities in
the form of double frees, but nobody has shown a single piece of code
that would do that.  So I'd say we're in the process of convincing you
that the change is safe.  It would help if you'd show a minimal
reproducible example program in which you expect to introduce a
vulnerability after this change.

Have a lovely day!
Alex

> 
> 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/20241024/2e8d289c/attachment-0001.sig>