[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <nd4nq27aqgeljkkneuxneybvemnsq7qcx6pmcmx7whg3fjzcnx@wo4cnvclda65>
Date: Tue, 17 Jun 2025 23:58:35 +0200
From: Alejandro Colomar <alx@...nel.org>
To: enh <enh@...gle.com>, Florian Weimer <fweimer@...hat.com>
Cc: Rich Felker <dalias@...c.org>,
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: Re: BUG: realloc(p,0) should be consistent with malloc(0)
Hi Elliott, Florian,
glibc and Bionic are non-conforming to POSIX.1-2024. The fix that we're
proposing would make them conforming. Does conformance to POSIX.1-2024
mean something to you?
RETURN VALUE
If size is 0,
...
either:
- A null pointer shall be returned
and, if ptr is not a null pointer,
errno shall be set to EINVAL.
- A pointer to the allocated space shall be returned,
and the memory object pointed to by ptr shall be freed.
...
Please also reply to the message about my proposal for the C Committee.
And Elliott, thanks for noticing that Windows is also crap. That's
another one to add to the list.
Have a lovely day!
Alex
On Tue, Jun 17, 2025 at 12:13:03PM -0400, enh wrote:
> On Tue, Jun 17, 2025 at 10:51 AM Rich Felker <dalias@...c.org> wrote:
> >
> > On Tue, Jun 17, 2025 at 10:07:07AM -0400, enh wrote:
> > > 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...
> >
> > I'm not sure what you mean by "not having heard anyone but you bring
> > this up in the last 15 years". This has been a recurring issue on the
> > glibc bug tracker and in C and POSIX committees, and comes up all the
> > time with users of the language not understanding what the standard
> > says or if/how implementations are conforming. There have been
> > multiple bug reports against different versions of the wording in
> > different versions of the C and POSIX standards, and it's a perpetual
> > source of disagreements.
>
> yeah, i should probably have said that in my weighting, arguments over
> standards count for nothing compared to existing practice, and only
> "i'm a developer who had a real problem because of this" warrants a
> behavior change. (with my biggest quandary is actually cases exactly
> like this where ios -- which most app developers care about
> compatibility with -- and glibc -- which linux tool developers care
> about -- disagree. as for Windows, that mostly comes up in relation to
> game developers.)
>
> but, yeah, in 15 years of having both groups complain at me, i've yet
> to see or hear about a single "my code works on ios but not on
> android" bug from this, and obviously we're the same as glibc so
> there's been nothing there.
>
> > Indeed fixing the bug will not make any immediate improvement. For
> > decades applications will still need to assume they might be running
> > on a system with the broken (inconsistent) behavior like glibc or
> > Bionic, or apply a wrapper to fix it (ala gnulib). But maybe
> > eventually that can become a bad chapter of history we leave behind.
> >
> > One thing I kinda would like to think about is if there's a way we can
> > signal at compile-time (without run tests that don't work for cross
> > compiling) that realloc is non-broken and doesn't need gnulib-style
> > wrapping/replacement. My hope is that such a mechanism would follow
> > the principles of the "Macro-based advertisement of libc extensions"
> > proposal on libc-coord.
> >
> > Rich
--
<https://www.alejandro-colomar.es/>
Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)
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.
