Paul Eggert wrote:
> * lib/string.in.h (memchr, strchr, strpbrk, strrchr):
> Do not #undef when GNULIB_POSIXCHECK is defined, as this could
> cause conforming C23 code to fail to conform.
This looks correct:
- In C mode, _GL_WARN_ON_USE (function, ...) and
_GL_WARN_ON_USE_CXX (function, ...) expand to something
that uses the given function _only_ in a position that does
not have a following opening parenthesis. Therefore, a macro
definition of the function *with arguments* (like the one in
Joseph Myers' glibc commit cd748a63ab1a7ae846175c532a3daab341c62690)
should not cause a syntax error.
- In C++ mode, we assume that these identifiers are not defined
as macros, as this would cause trouble in C++ classes that uses members
with these names.
> It’s not clear why
> _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.
> But for now, limit the removal of #undef to these four functions
> where #undeffing is clearly undesirable in C23.
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?
Bruno
