On 2026-02-22 00:52, Bruno Haible wrote:
to me, accepting a 'void *' argument here looks like a bug in
n3020.pdf page 7 and in glibc.
As far as I know glibc is the only released C library that supports this
C23 feature. Jens Gustedt submitted a patch for musl that agrees with
glibc and with N3020; see
<https://forge.icube.unistra.fr/icps/musl/-/commit/a6fc4ae313c0362fadb2db179d781da850995c21>.
So if it is a bug it's looking like it's a reasonably popular one.
1. Gnulib lib/string.in.h should contain a comment saying that its
strnul is stricter with void pointers than glibc's strchr, and why.
I would prefer to get this fixed in glibc.
Regardless of whether it's fixed in glibc, we should document the
discrepancy/bug/whatever, as the issue exists now with current glibc and
current Gnulib.
2. The Gnulib internal function should be renamed from gl_strchr to
__gl_strchr to make it obvious to the reader that it's private to the
implementation.
I disagree with this: Gnulib is application code and therefore has no
business in defining symbols that start with '__', which are reserved
for use by the system (= compiler and libc).
Here, Gnulib is part of the system: it's implementing string.h. There's
precedent for using __gl_ prefixes in this situation, e.g.,
lib/stdbit.in.h. There's also precedent for using gl_ prefixes, but when
gl_ is used it's not always clear whether the symbols are intended to be
private, which is unfortunate. I won't insist on renaming gl_strchr but
it *is* a confusing name for that reason.
3. The Gnulib test for whether _Generic is supported is semi-duplicated
in lib/cdefs.h (copied from glibc) and in lib/string.in.h. The tests
should agree. A quick look suggests that neither approach strictly
dominates the other so a merge needs to take place.
In my reading, the one in lib/string.in.h and lib/string-desc.h is a
superset of the one in lib/cdefs.h.
The definition in lib/cdefs.h (copied from glibc) should better be
updated
- to reflect that _Generic works also in C++ mode with clang,
- to add (defined __SUNPRO_C && __SUNPRO_C >= 0x5150)
Thanks, I'll add that to my list of things to do.
