I might have to release #djbwares 12 hot on the heels of 11.
Bloody C.
#StandardC
Excellent news! Thank you.
The warnings are mainly Bernstein's buffer library relying upon being able to use one function pointer to point to multiple different functions with different signatures (which is a shenanighan that one could play with old C, but soon no longer) and Bernstein's byte library using char pointers.
I've fixed a load of places where the Bernstein code was blasé about function signatures. Those are two of the remaining unfixed areas.
A bonus top tip for today:
'\376' will not compare equal to a character in memory with the value 254.
This is not assembly language, where one can compare an 8-bit byte with an 8-bit constant and have it just work, willy-nilly.
That would be crazy.
This is a very old wrinkle, that pre-dates Unicode. I remember this going around on Usenet.
The locale's collation order affects character ranges.
The "Welsh or Standard C library function?" questionnaire gave me a chuckle. Sadly, I recognized the library functions immediately. (-:
You've built a argument on the assumption of binary incompatibility, but in fact there was none.
There was no layout change nor symbol name changes.
The struct layout stayed entirely the same. The struct definition merely moved from one header to another and replaced the declarations of some members with external library types rather than their underscored aliases that standard headers use.
The thing that would have introduced binary incompatibility, which #OpenBSD has had to deal with this year, #FreeBSD had already done 7 years earlier back in 2001, and is still the case now.
By 2008, it was just moving struct definitions out of a standard header and removing "inline" macros. The one thing in base that that broke in 2008 (because of *source* incompatibility) went away in 2011, and Jordan Hubbard patched some stuff in ports a decade ago.
It is entirely feasible in 2025 for FreeBSD to regain parity with OpenBSD quite simply.
So … are any #FreeBSD developers up to reinstating John Baldwin's change from 2008 and bringing FreeBSD back to parity with #OpenBSD?
https://cgit.freebsd.org/src/commit/include/stdio.h?id=c17bf9a9a5a3b59e03108b785f6b15070ff25651
You really should tell the #BusyBox people about that C bug in the feature autodetection.
I recently had to update a whole lot of K&R code (written a decade after C89) for similar reasons. I even had a similar autodetection break.
C99 has and C23 is even more going to hit a lot of old codebases where people wrote things K&R style, sadly in the cases of many of them well after #StandardC came into existence.
I remember this one from the 1990s. Unless one carefully retains the same structure layout, everything that uses getc(), putc(), and fileno() at minimum is broken until recompiled from source.
It's interesting comparing Usenet of 1993 to Hacker News of today. Some questions are perennial, it seems:
"But what use is malloc(0)?" followed by a discussion of people rolling their own Pascal-like strings.
"Why unique?" followed by a discussion of making sets and maps.
"It's not a valid pointer." leading to the usual pantomime rejoinder.
I haven't seen anyone ask what the old implementations that returned NULL did to errno, though.
Back in 1993, #AIX was the example that people gave of a C library where malloc(0) returned NULL.
https://groups.google.com/g/comp.unix.aix/c/lstmVEcmD2Q/m/wRsWt_Tnw1UJ
Most of the C libraries that I touched back then either just handed off to the operating system's API for suballocation, which did not treat zero specially, or had their own suballocation functions, which did not treat zero specially.
Well they *are* making their own versions of those two macros. I'd already read the ostensible rationale for it, and it seemed poor.
They have a problem with their own code's headers having lots of cross-dependencies. (Strong coupling and low cohesion: a long-standing #systemd problem.) That's not a reason for fiddling with the #StandardC library, let alone making one's own FILE and DIR macros.
I understood Daniel J. Bernstein's avoidance of the Standard C library, especially strings and standard I/O which had been rife with pointer mis-uses for decades.
But this is not that.
Why on Earth would one continue to use stdio but roll one's own version of the GNU C library's FILE and DIR macros?
https://github.com/systemd/systemd/issues/37779#issuecomment-2952813363
Client Info
Server: https://mastodon.social
Version: 2025.07
Repository: https://github.com/cyevgeniy/lmst