Hi Paul, On 2026-02-23T02:14:42-0800, Paul Eggert wrote: > 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.
There's a more recent patch by me, although it hasn't been merged yet. BTW, I found a mistake, so I've sent a revised version a moment ago. I've CCed all of you. Have a lovely day! Alex > > > > 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. -- <https://www.alejandro-colomar.es>
signature.asc
Description: PGP signature
