On Wed, Jun 18, 2025 at 11:20:54AM -0400, enh wrote: > 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.)
I have not yet read the issues leading up to the change in detail, but it looks like POSIX made 2 changes that might have been framed as 1. The first is soft-removing the allowance for malloc(0) to return a null pointer on success, by making this option technically a "failure" for "invalid size", where any implementation that really wants to keep doing what it's doing could theoretically just add errno=EINVAL; to remain conforming. To me this seems like a breaking change, since a caller that's doing the previously-right errno-checking dance would now interpret it as failure rather than success. However, I suspect what they found is that there were no relevant implementations where malloc(0) returns 0, and thereby that it doesn't matter and nothing is broken. The second change is applying the first to realloc, which would be noncontroversial and wouldn't be a distinct chance except for the fact that realloc(p,0) was already inconsistent with malloc(0) on a few implementations. And this is a hard functional change. Since realloc returning 0 is now mandated to be an error condition, it's required that implementations where realloc(p,0) return 0 leave p alone and don't free it. I agree that making this change that's contrary to existing practice and without discussing it with those implementors to reach consensus is a bug, if indeed that's what happened. We should probably look at how this happened. Rich
