Hi Collin, > Date: 2026-08-01 18:04:05-0700 > From: Collin Funk <[email protected]> > > Alejandro Colomar <[email protected]> writes: > > >> I'd like to underscore this point. As I noted in my response to Doug, > >> the flagship book on C, as we all know, is stuck in 1988. The throne is > >> vacant, with many pretenders, some with excellent cases for service as > >> regent. > > > > In fact, the throne might currently fall in the Linux man-pages project. > > While not being a blood heir of the Unix standards, it has become a > > de-facto standard. > > I don't think anyone is arguing whether or not man-pages is an > educational tool. The argument is whether it should educate based on > current standards, or the maintainers preferences.
I'm not innovating if I say that the standards are mostly ignored.
Actually, I am more in the side of following the standards as much as
possible and appropriate (but not more) on average.
This is just a case where educating on the current standards is done by
1) documenting at the bottom of the manual what the standard says, and
2) recommending to ignore it because it's bad. When the standards are
bad, this is appropriate course.
The manual pages should certainly educate about reality, and standards
are only secondary to that.
This reminds me of realloc(3). That's a perfect example of educating
based on current (and withdrawn) standards. And the education might
very well consist of saying "don't listen to the standards in this case;
they're bad for you".
I expect we'll be able to fix realloc(p,0) eventually, and Microsoft is
working with me on that.
STANDARDS
...
realloc(p, 0)
The behavior of realloc(p, 0) in glibc doesn’t conform to
any of C99, C11, POSIX.1‐2001, POSIX.1‐2004, POSIX.1‐2008,
POSIX.1‐2013, POSIX.1‐2017, or POSIX.1‐2024. The C17
specification was changed to make it conforming, but that
specification made it impossible to write code that reli‐
ably determines if the input pointer is freed after real‐
loc(p, 0), and C23 changed it again to make this undefined
behavior, acknowledging that the C17 specification was
broad enough, so that undefined behavior wasn’t worse than
that.
reallocarray() suffers the same issues in glibc.
musl libc and the BSDs conform to all versions of ISO C
and POSIX.1.
gnulib provides the realloc‐posix module, which provides
wrappers realloc() and reallocarray() that conform to all
versions of ISO C and POSIX.1.
There’s a proposal to standardize the BSD behavior: https:
//www.open-std.org/jtc1/sc22/wg14/www/docs/n3621.txt.
HISTORY
...
realloc(p, 0)
C89 was ambiguous in its specification of realloc(p, 0).
C99 partially fixed this.
The original implementation in glibc would have been con‐
forming to C99. However, and ironically, trying to comply
with C99 before the standard was released, glibc changed
its behavior in glibc 2.1.1 into something that ended up
not conforming to the final C99 specification (but this is
debated, as the wording of the standard seems self‐contra‐
dicting).
...
BUGS
Programmers would naturally expect by induction that
realloc(p, size) is consistent with free(p) and mal‐
loc(size), as that is the behavior in the general case.
This is not explicitly required by POSIX.1‐2024 or C11,
but all conforming implementations are consistent with
that.
The glibc implementation of realloc() is not consistent
with that, and as a consequence, it is dangerous to call
realloc(p, 0) in glibc.
A trivial workaround for glibc is calling it as
realloc(p, size?size:1).
The workaround for reallocarray() in glibc ——which shares
the same bug—— would be
reallocarray(p, n?n:1, size?size:1).
Have a lovely night!
Alex
>
> Collin
--
<https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
