Hi Rich, Elliott, On Wed, Jun 18, 2025 at 12:35:50PM -0400, Rich Felker wrote: > 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...
Not most. Only two POSIX implementations, plus Windows. And the solution is easy: fix the implementations. There have been no regression reports in gnulib since we fixed it last year. > > (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.) It's ironic that the standard should have never said that, because prior to the existence of ANSI C and POSIX, all existing systems behaved like the current POSIX specification. It was a consequence of the horrible wording of the standards, that glibc was written so badly, by following a bogus specification, when it should have been made compatible with the existing systems. Thus, this is a historical bug in ISO C, POSIX, which at least has been finally fixed in POSIX. BTW, the same text is present in POSIX.1-2017. It was changed in a TC, following bug <https://www.austingroupbugs.net/view.php?id=400>. The motivation, from what I can read there, seems to be that C99 already made POSIX.1 non-conforming, and this fix was intended to conform to C99. Indeed, glibc is non-conforming to C99 too. Although, I don't like the wording from C99, either; it allows weird stuff: it allows an implementation where malloc(0) returns NULL and realloc(p,0) non-null (so, the opposite of glibc). C11 is essentially identical to C99 in that regard, so glibc is also non-conforming to C11. C17 changed to something very weird. It seems to me that glibc is conforming again to C17, but it also seems to me that it's impossible to write code that uses realloc(p,0) in a portable way with this specification. I think it's a good thing that C23 removed that crap. Here's a summary of conformance to standards: glibc conforms to: - SysVr4 - ISO C89 - ISO C17 - XPG4 glibc doesn't conform to: - SysIII - SysV - SysVr2 - SysVr3 - SVID Issue 2 - SVID Issue 3 - The X/Open System V Specification - ISO C99 - ISO C11 - POSIX.1-2001 - POSIX.1-2008 - POSIX.1-2017 - POSIX.1-2024 Conformance to POSIX.1-2001 and POSIX.1-2008 is not clear. While glibc conforms to the wording of these standards, these standards have the following header in the realloc(3) specification: The functionality described on this reference page is aligned with the ISO C standard. Any conflict between the requirements described here and the ISO C standard is unintentional. This volume of IEEE Std 1003.1-2001 defers to the ISO C standard. Which means that POSIX's permissive wording is unintentional, and the ISO C99 wording is the one that matters, so glibc is non-conforming. (I didn't mention C23, since it's UB, so anything conforms.) Have a lovely day! Alex -- <https://www.alejandro-colomar.es/>
signature.asc
Description: PGP signature
