On 2025-11-23 14:57, Bruno Haible wrote:
Paul Eggert wrote:It’s not clear why #undef is needed before others uses of _GL_WARN_ON_USE and _GL_WARN_ON_USE_CXX; perhaps it was needed but isn’t any more?The _GL_WARN_ON_USE_CXX on three of these functions was introduced in gnulib commit 467fb4fcc12e1c1e2f20417272feb740566ecc6e, see https://lists.gnu.org/archive/html/bug-gnulib/2020-05/msg00099.html, and there's nothing that makes me believe that the problem has gone away.
Unfortunately I'm not understanding the connection. That email is about C++, but m4/posixcheck.m4 defines GNULIB_POSIXCHECK only for C. That is, the #undefs that I'm talking about are for C, not for C++.
Does current gnulib (a testdir of all modules) build fine for you with the newest glibc, including Joseph Myers' patch? Or are there other compilation errors?
I haven't built such a testdir against bleeding-edge glibc, only against glibc with Joseph's qualifier-generic patch (for strchr etc.). It builds OK both with and without the attached (compressed) Gnulib patch.
Any reason not to install the attached patch? It simplifies Gnulib, and it would avoid future problems like what we ran into with C23 strchr, as I expect we will in the future with strchrnul etc.
PS. There are also a bunch of GCC warnings like this:argp-parse.c:730:27: warning: call to 'strchr' declared with attribute warning: strchr cannot work correctly on character strings in some multibyte locales - use mbschr if you care about internationalization [-Wattribute-warning]
which I assume are irrelevant to this issue. These warnings perhaps should be in a different category than GNULIB_POSIXCHECK as they are about multibyte usage not about POSIX compatibility. They're surely false alarms for Gnulib itself.
0001-snippet-warn-on-use-don-t-undef-before-_GL_WARN_ON_U.patch.gz
Description: application/gzip
