bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Issues with _GL_CXXALIAS_SYS (strndup)


From: Martin Storsjö
Subject: Issues with _GL_CXXALIAS_SYS (strndup)
Date: Fri, 3 Jan 2020 01:04:46 +0200 (EET)
User-agent: Alpine 2.20 (DEB 67 2015-01-07)

Hi,

When building a test package shared in https://savannah.gnu.org/bugs/?57406 (https://haible.de/bruno/gnu/testdir-posix-mingw.tar.gz) with my mingw/clang/libc++ based toolchain, I ran into some errors in the gltests subdirectory.

One of the issues looks like this:

../gllib/string.h:920:19: error: no member named 'strndup' in the global namespace; did you mean 'strdup'?
_GL_CXXALIAS_SYS (strndup, char *, (char const *__s, size_t __n));
~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/sys/socket.h:269:20: note: expanded from macro '_GL_CXXALIAS_SYS'
          return ::func;                                      \
                 ~~^
../gllib/string.h:872:19: note: 'strdup' declared here
_GL_CXXALIASWARN (strdup);
                  ^
../gllib/string.h:920:1: error: cannot initialize return object of type 'gnulib::_gl_strndup_wrapper::type' (aka 'char *(*)(const char *, unsigned long long)') with an lvalue of type 'typeof (strdup)' (aka 'char *(const char *)'): different number of parameters (2 vs 1)
_GL_CXXALIAS_SYS (strndup, char *, (char const *__s, size_t __n));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../gllib/sys/socket.h:269:18: note: expanded from macro '_GL_CXXALIAS_SYS'
          return ::func;                                      \
                 ^~~~~~

../gllib/string.h:922:19: error: use of undeclared identifier 'strndup'; did you mean 'strdup'?
_GL_CXXALIASWARN (strndup);
                  ^
../gllib/string.h:872:19: note: 'strdup' declared here
_GL_CXXALIASWARN (strdup);
                  ^

The root cause for this issue seems to be that clang has a builtin for the strndup function, even if the target platform actually doesn't have it.

This manifests itself during configure like this:

configure:31903: checking whether strndup is declared
configure:31903: x86_64-w64-mingw32-gcc -c -g -O2  conftest.c >&5
conftest.c:267:10: warning: implicitly declaring library function 'strndup' with type 'char *(const char *, unsigned long long)' [-Wimplicit-function-declaration]
  (void) strndup;
         ^
conftest.c:267:10: note: include the header <string.h> or explicitly provide a declaration for 'strndup'
1 warning generated.
configure:31903: $? = 0
configure:31903: result: yes

This results in variables set up like this:

ac_cv_func_strndup=no
ac_cv_have_decl_strndup=yes

GNULIB_STRNDUP = 1
HAVE_DECL_STRNDUP = 1
REPLACE_STRNDUP = 0

Which then leads to the errors quoted above. I presume this is a case of an unexpected combination of flags that lead to this situation, which makes the gnulib string.h (when included from C++) produce this error.

I guess one could argue that one should fix clang not to expose builtins for things the target platforms doesn't support though, but given these configure test results, is this something that gnulib could react to differently?

// Martin




reply via email to

[Prev in Thread] Current Thread [Next in Thread]