musl - Re: BUG: realloc(p,0) should be consistent with malloc(0)

Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ngw4edsadm66g274opp3uo2mijpgukw4pgzuo6kka5nsji5kom@jsxtvjedv24f>
Date: Mon, 16 Jun 2025 23:44:48 +0200
From: Alejandro Colomar <alx@...nel.org>
To: Florian Weimer <fweimer@...hat.com>
Cc: Adhemerval Zanella Netto <adhemerval.zanella@...aro.org>, 
	musl@...ts.openwall.com, libc-alpha@...rceware.org, Joseph Myers <josmyers@...hat.com>, 
	наб <nabijaczleweli@...ijaczleweli.xyz>, Paul Eggert <eggert@...ucla.edu>, 
	Robert Seacord <rcseacord@...il.com>, Elliott Hughes <enh@...gle.com>, Bruno Haible <bruno@...sp.org>, 
	bug-gnulib@....org, JeanHeyd Meneide <phdofthehouse@...il.com>
Subject: Re: BUG: realloc(p,0) should be consistent with malloc(0)

Hi Florian,

On Mon, Jun 16, 2025 at 09:35:01PM +0200, Florian Weimer wrote:
> * Adhemerval Zanella Netto:
> 
> > I have re-read the whole thread and it seems that most maintainers are OK
> > with this change and agree that current POSIX's realloc spec has some 
> > drawbacks (albeit it still allows current glic behavior).
> >
> > The only one involved in the previous thread that raised some objection to
> > this change was Joseph [1], but I will let to say if he still think this
> > potential change to glibc is ill-advised.
> 
> I objected then, and I'm objecting now as well.
> 
> My rationale has not changed:
> 
> <https://inbox.sourceware.org/libc-alpha/8734kl1pim.fsf@oldenburg.str.redhat.com/>
> 
> I believe Siddhesh's proposed patch as the time was mostly a device to
> drive the discussion to a conclusion, which it did.

I'll quote your rationale from the link:

| * Siddhesh Poyarekar:
| | Nope, please read the threads carefully; I actually said that I won't
| | sustain an objection if I'm the only one holding that opinion.
| 
| I'm still objecting, I don't think this change is valuable.
| 
| I'm open to looking at this again once the C standard fully specifies
| the behavior of zero-sized objects, the return value of malloc (0), and
| so on.

I'm working on that.  I have a proposal for mandating that malloc(0),
but I can't present it until realloc(p, 0) is fixed.  And the
C Committee has refused to fix realloc(p, 0) by decree, so until the
remaining implementations that are broken fix their implementations, we
can't think of having the standard fixed.

Since glibc and Bionic are the two implementations that are currently
broken, could you please fix your implementations?  I'm sure the
C Committee will be much easier to convince if the implentations have
changed in a clear direction.

But if the committee says we're not fixing ISO C until the
implementations are fixed, and the implementations (you) refuse to
accept the fix until the committee standardizes something, then we'll
have the problem forever.

Also, I want to propose 0-length arrays when the arrays are parameters
to functions:

	char *stpecpy(char *dst, char end[0], const char *restrict src);

But again, I can't present this proposal until another one that makes
[n] more meaningful than it is now is merged.  Martin Uecker presented
that one, and I'm waiting for him to sent a revision of his proposal.

So, I'm working in various fronts on having 0-length arrays in the
standard, but there are dependencies before I can propose them.

| Getting aligned behavior between implementations on these
| fundamental interfaces seems quite valuable to programmers.

glibc and Bionic are the only implementations in which realloc(p,0) is
different from free(p) malloc(0).  Fixing glibc (and assuming Bionic
agrees and follows) will solve the problem.

|  But
| addressing one zero-object-size case and leaving all the others as
| unclear as before doesn't seem to be useful,

I have plans to address the other 0-size objects.  Give me time.

| especially given that a
| ffuture standard may require different behavior anyway.

The C Committee seems in favour of removing the UB from realloc(p,0) if
the implementations are fixed first.  Now it's your turn to move.

I'm sure I can convince the committee to follow existing practice.

But I can go a step further:

How about I write a proposal to the committee, in which I talk about the
current situation, and how glibc and Bionic are the only broken
implementation, and propose a change to ISO C which blesses the behavior
of all other implementations, rendering glibc and Bionic non-conforming?
I can then propose a very explicit question:

	If glibc and Bionic agreed to change their behavior according to
	this proposal, would the C Committee agree to this change?

And then come back to glibc with that.  If I get such a conditional
approval of such a proposal, would glibc then apply the fix?

|  A
| piece-by-piece transition to the newly required behaviors is also more
| onerous on programmers than one well-defined transition in a single
| glibc release.

The realloc(p, 0) is not onerous on programmers at all.  See how the
gnulib went smoothly.  Or do you mean on the implementors?


Have a lovely day!
Alex

-- 
<https://www.alejandro-colomar.es/>

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.