[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAJgzZopU2xDpuYkbJ-W9rURTCFL0tQEYrXKYu7rmkG+UVZzVKw@mail.gmail.com>
Date: Wed, 18 Jun 2025 11:20:54 -0400
From: enh <enh@...gle.com>
To: Alejandro Colomar <alx@...nel.org>
Cc: Florian Weimer <fweimer@...hat.com>, 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)
On Tue, Jun 17, 2025 at 5:58 PM Alejandro Colomar <alx@...nel.org> wrote:
>
> 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?
not when POSIX screwed up and made a change that made most of the
existing implementations non-conformant, no. that sounds like a POSIX
bug to me...
(like i said, i care greatly about actual shipping code. a standard is
interesting for green-field stuff, but when it's at odds with reality
it's often worse to try to adapt than just ignore the stupidity/report
the bug and get it changed back.)
> 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/>
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.
