On Tue, Jun 17, 2025 at 5:58 PM Alejandro Colomar <a...@kernel.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 <dal...@libc.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 <a...@kernel.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....@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/>
