[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZooXcPUVJ7Z3Nae-2WRsjpFnNVZpGU0aJyysM2Mv89PSgg@mail.gmail.com>
Date: Tue, 17 Jun 2025 10:07:07 -0400
From: enh <enh@...gle.com>
To: Alejandro Colomar <alx@...nel.org>
Cc: Florian Weimer <fweimer@...hat.com>,
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>, 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)
On Mon, Jun 16, 2025 at 5:44 PM Alejandro Colomar <alx@...nel.org> wrote:
>
> 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.
is it really a problem though? you're basically asking to _add_ an
incompatibility with existing versions of glibc/bionic (so, you know,
"basically every non-Windows computer out there").
from my perspective:
pros:
+ code would then behave the same on android and ios
cons:
- code would behave differently on different versions of android
- code would behave differently on the host
unknowns:
? what does Windows do?
? does anyone actually care?
not having heard anyone but you bring this up in the last 15 years
(despite it apparently being an android/ios difference), i'm inclined
to assume this is a non-problem that's not worth the disruption of
changing anything...
> 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/>
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
