cannot figure out how to work with GNULIB_NAMESPACE without warnings

cannot figure out how to work with GNULIB_NAMESPACE without warnings

[Alexandre Duret-Lutz]

Hi

Testing my updated version of gnulib (as specified yesterday
in https://lists.gnu.org/archive/html/bug-gnulib/2021-01/msg00177.html)

I ran into the following linking issue, which I did not have 8 months ago.

/usr/bin/i686-w64-mingw32-ld: misc/.libs/libmisc.a(satsolver.o): in function `ZNSt13basic_filebufIcSt11char_traitsIcEED4Ev':
/usr/lib/gcc/i686-w64-mingw32/10-posix/include/c++/fstream:249: undefined reference to `std::basic_filebuf<char, std::char_traits<char> >::rpl_close()'
collect2: error: ld returned 1 exit status

[That's a cross compilation for MinGW, obviously.]

Since this seems to the kind of error documented on
https://www.gnu.org/software/gnulib/manual/html_node/A-C_002b_002b-namespace-for-gnulib.html
I tried to do

   AC_DEFINE_UNQUOTED([GNULIB_NAMESPACE], [gnulib])

(knowing that I would then have to track down the use of many replaced
function, and prefix them with gnulib::)

However then compilation failed with a message telling me that a
system-installed header should use gnulib::vsnprintf instead
of std::vsnprintf!

libtool: compile:  clang++ -Qunused-arguments -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../buddy/src -I../../lib -I../../lib -W -Wall -Werror -Wint-to-void-pointer-cast -Wcast-align -Wpointer-arith -Wwrite-strings -Wcast-qual -DXTSTRINGDEFINES -Wdocumentation -Wmissing-declarations -Woverloaded-virtual -Wmisleading-indentation -Wimplicit-fallthrough -Wnull-dereference -Wsuggest-override -Wpedantic -fvisibility=hidden -fvisibility-inlines-hidden -DSPOT_BUILD -std=c++20 -g -O -MT clz.lo -MD -MP -MF .deps/clz.Tpo -c clz.cc  -fPIC -DPIC -o .libs/clz.o
In file included from bitvect.cc:23:
In file included from ../../spot/misc/bitvect.hh:22:
In file included from ../../spot/misc/common.hh:21:
In file included from /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/stdexcept:39:
In file included from /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/string:55:
/usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/basic_string.h:6652:50: error: The symbol ::vsnprintf refers to the system function. Use gnulib::vsnprintf instead. [-Werror,-Wuser-defined-warnings]
    return __gnu_cxx::__to_xstring<string>(&std::vsnprintf, __n,
                                                 ^
../../lib/stdio.h:2104:1: note: from 'diagnose_if' attribute on 'vsnprintf':
_GL_CXXALIASWARN (vsnprintf);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:382:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:384:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:389:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:553:19: note: expanded from macro '_GL_WARN_ON_USE'
  __attribute__ ((__diagnose_if__ (1, message, "warning")))
                  ^                ~

This was clang++ 11.0.0 on Arch linux.


Since the original issue I have is with rpl_close(), and that I don't
really care about the issues it fixes, I've tried to use "gnulib-tool
--avoid=close" but in that case I get "#define close _close", which does
not help either.


Any clue ?
-- 
Alexandre Duret-Lutz

Re: cannot figure out how to work with GNULIB_NAMESPACE without warnings

[Bruno Haible]

Hi Alexandre,

> I ran into the following linking issue, which I did not have 8 months ago.
> 
> /usr/bin/i686-w64-mingw32-ld: misc/.libs/libmisc.a(satsolver.o): in function `ZNSt13basic_filebufIcSt11char_traitsIcEED4Ev':
> /usr/lib/gcc/i686-w64-mingw32/10-posix/include/c++/fstream:249: undefined reference to `std::basic_filebuf<char, std::char_traits<char> >::rpl_close()'
> collect2: error: ld returned 1 exit status
> 
> [That's a cross compilation for MinGW, obviously.]
> 
> Since this seems to the kind of error documented on
> https://www.gnu.org/software/gnulib/manual/html_node/A-C_002b_002b-namespace-for-gnulib.html
> I tried to do
> 
>    AC_DEFINE_UNQUOTED([GNULIB_NAMESPACE], [gnulib])

Right. In a C compilation, the recommendation would be "Include <unistd.h> first,
so that 'close' gets defined to 'rpl_close' early enough." But in C++, it is
easier and more robust to define GNULIB_NAMESPACE.

> However then compilation failed with a message telling me that a
> system-installed header should use gnulib::vsnprintf instead
> of std::vsnprintf!
> 
> libtool: compile:  clang++ -Qunused-arguments -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../.. -I../../buddy/src -I../../lib -I../../lib -W -Wall -Werror -Wint-to-void-pointer-cast -Wcast-align -Wpointer-arith -Wwrite-strings -Wcast-qual -DXTSTRINGDEFINES -Wdocumentation -Wmissing-declarations -Woverloaded-virtual -Wmisleading-indentation -Wimplicit-fallthrough -Wnull-dereference -Wsuggest-override -Wpedantic -fvisibility=hidden -fvisibility-inlines-hidden -DSPOT_BUILD -std=c++20 -g -O -MT clz.lo -MD -MP -MF .deps/clz.Tpo -c clz.cc  -fPIC -DPIC -o .libs/clz.o
> In file included from bitvect.cc:23:
> In file included from ../../spot/misc/bitvect.hh:22:
> In file included from ../../spot/misc/common.hh:21:
> In file included from /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/stdexcept:39:
> In file included from /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/string:55:
> /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/basic_string.h:6652:50: error: The symbol ::vsnprintf refers to the system function. Use gnulib::vsnprintf instead. [-Werror,-Wuser-defined-warnings]
>     return __gnu_cxx::__to_xstring<string>(&std::vsnprintf, __n,
>                                                  ^

The use of '-Werror' has distorted your view of what warnings are about.

Warnings are not a means to make your compilation fail.

Warnings are a means to give you, the developer, some hints about possible/
suggested changes to your program.

In this case, Gnulib gives you the hint: Attention, you are using ::vsnprintf,
which has many bugs, as documented in
<https://www.gnu.org/software/gnulib/manual/html_node/vsnprintf.html>
Suggestion: use gnulib::vsnprintf instead.

You decide whether to follow this suggestion. If you follow it, this warning
will disappear. If you don't follow it, at the end of going through all
warnings, you add '-Wno-user-defined-warnings' to your CPPFLAGS, and are done
with it.

Bruno

Re: cannot figure out how to work with GNULIB_NAMESPACE without warnings

[Alexandre Duret-Lutz]

Hi Bruno!

Bruno Haible <bruno@clisp.org> writes:

> in C++, it is easier and more robust to define GNULIB_NAMESPACE.

OK, thanks, I'll progress this way.

>> /usr/sbin/../lib64/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/bits/basic_string.h:6652:50: error: The symbol ::vsnprintf refers to the system function. Use gnulib::vsnprintf instead. [-Werror,-Wuser-defined-warnings]
>
> You decide whether to follow this suggestion. If you follow it, this warning
> will disappear. If you don't follow it, at the end of going through all
> warnings, you add '-Wno-user-defined-warnings' to your CPPFLAGS, and are done
> with it.

I have a few questions about this:

- Would it be possible to provide a way to disable only the warnings
  emitted by _GL_CXXALIASWARN? (or maybe one of the macro it calls, I
  don't know where is the right place) Removing all user-defined
  warnings with -Wno-user-defined-warnings will hide other important
  messages.

  For instance libc++ uses diagnose_if attributes to warn about
  some common C++ errors.  They even provide a
  _LIBCPP_DISABLE_ADDITIONAL_DIAGNOSTICS macro to disable those.
  (this macro appears on https://libcxx.llvm.org/docs/UsingLibcxx.html)

- Is there a way to detect that the function is being called
  in a system header and use that in the diagnose_if condition?
  If possible, that would allow removing some false positives.
  In the case I reported, the warning about vsnprintf is
  in a system-header on a system where @REPLACE_VSNPRINTF@=0,
  so the warning is clearly noisy.

- Do I understand correctly that those warnings are supposed to be
  emitted everywhere I forgot to use the gnulib:: namespace before the
  call of a replaceable function?  Even on systems where no replacement
  function is used?  I did not see any such warning when I first
  compiled with g++ and GNULIB_NAMESPACE, and after reading the
  "drawback" paragraph near the end of page
  https://www.gnu.org/software/gnulib/manual/html_node/A-C_002b_002b-namespace-for-gnulib.html
  I assumed I was on my own to find all the places where gnulib::
  should be added.  It's only when some continuous integration
  builds failed that I discovered that clang++ would emit warnings [*].
  Having now looked at _GL_CXXALIASWARN it seems the warnings are
  disabled when GCC optimizes, which is the default with Autoconf.
  May this page could mention that some built-in help is available, and
  how to get it.  Something like:

     To help with finding function names that should be prefixed by
     gnulib::, Gnulib equips the original functions in the global
     namespace with an attribute that will trigger warnings when those
     functions are called.  This only works with g++ when not optimizing
     (-O0), or with clang++, so you may want to give one of these two
     compilers a go after you activate GNULIB_NAMESPACE.



[*] I would have not noticed those warnings if those builds were not
setup with -Werror.  That's one reason why I try to get warning-less
builds: so that I do not miss useful messages that appear only in some
build configurations.  Another reason is that I build a library; I want
the headers I install to follow the strictest standard I can, so that
users of those headers are not annoyed by warnings I could have avoided.
(Obviously I'm not installing the gnulib headers, so I have a bit more
freedom here.)

--
Alexandre Duret-Lutz

clang++ hard failure with GNULIB_NAMESPACE

[Alexandre Duret-Lutz]

Alexandre Duret-Lutz <adl@lrde.epita.fr> writes:

> Bruno Haible <bruno@clisp.org> writes:
>
>> in C++, it is easier and more robust to define GNULIB_NAMESPACE.
>
> OK, thanks, I'll progress this way.

Progress is not smooth.  This time it's unrelated to -Werror.

Using clang++ 11, compilation fails because of the overloads of memchr
and friends.  Note that clang++11 defines __GNUC__ and __GNU_MINOR__ as
4 and 2 (Yuck!) so the two _GL_CXXALIASWARN1 calls dealing with the two
overloads in lib/string.h are not performed.

In file included from bitvect.cc:28:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/cstring:42:
../../lib/string.h:693:1: error: reference to overloaded function could not be resolved; did you mean to call it?
_GL_CXXALIASWARN (memchr);
^~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:382:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:384:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:389:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:552:19: note: expanded from macro '_GL_WARN_ON_USE'
extern __typeof__ (function) function \
                  ^~~~~~~~~~
/usr/include/string.h:84:1: note: possible target for call
memchr (const void *__s, int __c, size_t __n) __THROW
^
/usr/include/string.h:78:1: note: possible target for call
memchr (void *__s, int __c, size_t __n) __THROW
^
In file included from bitvect.cc:28:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/cstring:42:
../../lib/string.h:807:1: error: reference to overloaded function could not be resolved; did you mean to call it?
_GL_CXXALIASWARN (rawmemchr);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:382:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:384:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:389:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:552:19: note: expanded from macro '_GL_WARN_ON_USE'
extern __typeof__ (function) function \
                  ^~~~~~~~~~
/usr/include/string.h:101:26: note: possible target for call
extern "C++" const void *rawmemchr (const void *__s, int __c)
                         ^
/usr/include/string.h:99:20: note: possible target for call
extern "C++" void *rawmemchr (void *__s, int __c)
                   ^
In file included from bitvect.cc:28:
In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/cstring:42:
../../lib/string.h:911:1: error: reference to overloaded function could not be resolved; did you mean to call it?
_GL_CXXALIASWARN (strchrnul);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:382:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:384:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:389:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../../lib/wchar.h:552:19: note: expanded from macro '_GL_WARN_ON_USE'
extern __typeof__ (function) function \
                  ^~~~~~~~~~
/usr/include/string.h:263:26: note: possible target for call
extern "C++" const char *strchrnul (const char *__s, int __c)
                         ^
/usr/include/string.h:261:20: note: possible target for call
extern "C++" char *strchrnul (char *__s, int __c)
                   ^
3 errors generated.
make[3]: *** [Makefile:1445: bitvect.lo] Error 1
make[2]: *** [Makefile:1549: all-recursive] Error 1
make[1]: *** [Makefile:1424: all-recursive] Error 1
make: *** [Makefile:1344: all] Error 2

-- 
Alexandre Duret-Lutz

Re: clang++ hard failure with GNULIB_NAMESPACE

[Bruno Haible]

Hi Alexandre,

> Using clang++ 11, compilation fails because of the overloads of memchr
> and friends.  Note that clang++11 defines __GNUC__ and __GNU_MINOR__ as
> 4 and 2 (Yuck!) so the two _GL_CXXALIASWARN1 calls dealing with the two
> overloads in lib/string.h are not performed.
> 
> In file included from bitvect.cc:28:
> In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/cstring:42:
> ../../lib/string.h:693:1: error: reference to overloaded function could not be resolved; did you mean to call it?
> _GL_CXXALIASWARN (memchr);
> ^~~~~~~~~~~~~~~~~~~~~~~~~

On which version of glibc do you see this?

On my machine, the testdir created through
  $ ./gnulib-tool --create-testdir --dir=../testdir4 --single-configure --with-c++-tests memchr rawmemchr strchrnul

compiles fine with clang 11 and these environment variable settings:

CC=$HOME/inst-clang/11.0.0/bin/clang
CXX="$HOME/inst-clang/11.0.0/bin/clang++ -L/usr/lib/gcc/x86_64-linux-gnu/5 -I/usr/include/c++/5 -I/usr/include/x86_64-linux-gnu/c++/5"
export CC CXX

Does this same testdir work for you? If yes, can you show a small .cc file
that exhibits the problem?

If I can't reproduce it, I'll have to ask you for appropriate modifications
of gnulib/lib/string.in.h that make things for work you.

Bruno

Re: clang++ hard failure with GNULIB_NAMESPACE

[Alexandre Duret-Lutz]

Hi Bruno

Bruno Haible <bruno@clisp.org> writes:

>> Using clang++ 11, compilation fails because of the overloads of memchr
>> and friends.
>> 
>> In file included from bitvect.cc:28:
>> In file included from /usr/bin/../lib/gcc/x86_64-linux-gnu/10/../../../../include/c++/10/cstring:42:
>> ../../lib/string.h:693:1: error: reference to overloaded function
>> could not be resolved; did you mean to call it?
>> _GL_CXXALIASWARN (memchr);
>> ^~~~~~~~~~~~~~~~~~~~~~~~~
>
> On which version of glibc do you see this?

This is the glibc packaged as "libc6 2.31-9" in Debian unstable.

> On my machine, the testdir created through
>   $ ./gnulib-tool --create-testdir --dir=../testdir4
> --single-configure --with-c++-tests memchr rawmemchr strchrnul
>
> compiles fine with clang 11 and these environment variable settings:
>
> CC=$HOME/inst-clang/11.0.0/bin/clang
> CXX="$HOME/inst-clang/11.0.0/bin/clang++
> -L/usr/lib/gcc/x86_64-linux-gnu/5 -I/usr/include/c++/5
> -I/usr/include/x86_64-linux-gnu/c++/5"
> export CC CXX
>
> Does this same testdir work for you?

No, the command

./configure CXX=clang++ && make

fails as follows:

clang++ -DHAVE_CONFIG_H -I. -I..  -DGNULIB_STRICT_CHECKING=1 -DIN_GNULIB_TESTS=1 -I. -I. -I.. -I./.. -I../gllib -I./../gllib   -g -O2 -MT test-string-c++.o -MD -MP -MF .deps/test-string-c++.Tpo -c -o test-string-c++.o test-string-c++.cc
In file included from test-string-c++.cc:22:
../gllib/string.h:693:1: error: reference to overloaded function could not be resolved; did you mean to call it?
_GL_CXXALIASWARN (memchr);
^~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:365:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:367:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:372:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:535:19: note: expanded from macro '_GL_WARN_ON_USE'
extern __typeof__ (function) function \
                  ^~~~~~~~~~
/usr/include/string.h:84:1: note: possible target for call
memchr (const void *__s, int __c, size_t __n) __THROW
^
/usr/include/string.h:78:1: note: possible target for call
memchr (void *__s, int __c, size_t __n) __THROW
^
In file included from test-string-c++.cc:22:
../gllib/string.h:807:1: error: reference to overloaded function could not be resolved; did you mean to call it?
_GL_CXXALIASWARN (rawmemchr);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:365:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:367:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:372:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:535:19: note: expanded from macro '_GL_WARN_ON_USE'
extern __typeof__ (function) function \
                  ^~~~~~~~~~
/usr/include/string.h:101:26: note: possible target for call
extern "C++" const void *rawmemchr (const void *__s, int __c)
                         ^
/usr/include/string.h:99:20: note: possible target for call
extern "C++" void *rawmemchr (void *__s, int __c)
                   ^
In file included from test-string-c++.cc:22:
../gllib/string.h:911:1: error: reference to overloaded function could not be resolved; did you mean to call it?
_GL_CXXALIASWARN (strchrnul);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:365:4: note: expanded from macro '_GL_CXXALIASWARN'
   _GL_CXXALIASWARN_1 (func, GNULIB_NAMESPACE)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:367:4: note: expanded from macro '_GL_CXXALIASWARN_1'
   _GL_CXXALIASWARN_2 (func, namespace)
   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:372:5: note: expanded from macro '_GL_CXXALIASWARN_2'
    _GL_WARN_ON_USE (func, \
    ^~~~~~~~~~~~~~~~~~~~~~~~
../gllib/string.h:535:19: note: expanded from macro '_GL_WARN_ON_USE'
extern __typeof__ (function) function \
                  ^~~~~~~~~~
/usr/include/string.h:263:26: note: possible target for call
extern "C++" const char *strchrnul (const char *__s, int __c)
                         ^
/usr/include/string.h:261:20: note: possible target for call
extern "C++" char *strchrnul (char *__s, int __c)
                   ^
3 errors generated.
make[4]: *** [Makefile:1542: test-string-c++.o] Error 1

> If I can't reproduce it, I'll have to ask you for appropriate modifications
> of gnulib/lib/string.in.h that make things for work you.

From what I understand, the problem is that:
   1) my version of string.h has two definitions of memchr for clang,
   2) the following snippet assumes that g++ < 4.4 should only see one,
      regardless of the glibc version
   3) clang++ masquerade as g++ 4.2.1

# if ((__GLIBC__ == 2 && __GLIBC_MINOR__ >= 10) && !defined __UCLIBC__) \
     && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4))
_GL_CXXALIASWARN1 (memchr, void *, (void *__s, int __c, size_t __n));
_GL_CXXALIASWARN1 (memchr, void const *,
                   (void const *__s, int __c, size_t __n));
# elif __GLIBC__ >= 2
_GL_CXXALIASWARN (memchr);
# endif


As a first approximation, I tried to simply change the condition to 

# if ((__GLIBC__ == 2 && __GLIBC_MINOR__ >= 10) && !defined __UCLIBC__) \
     && (__GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ >= 4) || __clang__)

but doing so still fail with

In file included from test-string-c++.cc:22:
../gllib/string.h:689:20: error: 'memchr' is missing exception specification 'throw()'
_GL_CXXALIASWARN1 (memchr, void *, (void *__s, int __c, size_t __n));
                   ^
/usr/include/string.h:78:1: note: previous declaration is here
memchr (void *__s, int __c, size_t __n) __THROW
^
In file included from test-string-c++.cc:22:
../gllib/string.h:690:20: error: 'memchr' is missing exception specification 'throw()'
_GL_CXXALIASWARN1 (memchr, void const *,
                   ^
/usr/include/string.h:84:1: note: previous declaration is here
memchr (const void *__s, int __c, size_t __n) __THROW
^

The relevant definitions of memchr in my copy of /usr/include/string.h

     35 /* Tell the caller that we provide correct C++ prototypes.  */
     36 #if defined __cplusplus && (__GNUC_PREREQ (4, 4) \
     37                             || __glibc_clang_prereq (3, 5))
     38 # define __CORRECT_ISO_CPP_STRING_H_PROTO
     39 #endif
     ..
     67 /* Search N bytes of S for C.  */
     68 #ifdef __CORRECT_ISO_CPP_STRING_H_PROTO
     69 extern "C++"
     70 {
     71 extern void *memchr (void *__s, int __c, size_t __n)
     72       __THROW __asm ("memchr") __attribute_pure__ __nonnull ((1));
     73 extern const void *memchr (const void *__s, int __c, size_t __n)
     74       __THROW __asm ("memchr") __attribute_pure__ __nonnull ((1));
     75 
     76 # ifdef __OPTIMIZE__
     77 __extern_always_inline void *
     78 memchr (void *__s, int __c, size_t __n) __THROW
     79 {
     80   return __builtin_memchr (__s, __c, __n);
     81 }
     82 
     83 __extern_always_inline const void *
     84 memchr (const void *__s, int __c, size_t __n) __THROW
     85 {
     86   return __builtin_memchr (__s, __c, __n);
     87 }
     88 # endif
     89 }
     90 #else
     91 extern void *memchr (const void *__s, int __c, size_t __n)
     92       __THROW __attribute_pure__ __nonnull ((1));
     93 #endif

If I preprocess the file, I can see the __THROW expands to "throw ()",
but that's the case for g++ as well.

The reason for the "g++ 4.4" threshold was that initially the definition
of __CORRECT_ISO_CPP_STRING_H_PROTO used only that:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=d8387c7b7b1c9ae92f924c33ba05790c98464d19

The change to the current definition is one year old:
https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=953ceff17a4a15b10cfdd5edc3c8cae4884c8ec3

I have reproduced these errors with clang++ 9, 10, and 11, but that
should not be surprising if __CORRECT_ISO_CPP_STRING_H_PROTO is
enabled for clang++ >= 3.5.
-- 
Alexandre Duret-Lutz