> Cc: gdb-patc...@sourceware.org, Thomas Schwinge <tho...@codesourcery.com> > From: Pedro Alves <pal...@redhat.com> > Date: Fri, 19 May 2017 16:22:55 +0100 > > But then, xstrndup.c has at the top: > > #ifdef HAVE_STRING_H > #include <string.h> > #else > # ifdef HAVE_STRINGS_H > # include <strings.h> > # endif > #endif > > So I would expect your build to pick the strnlen declaration from > one of the string.h or strings.h mingw headers. Why didn't it?
Because MinGW doesn't have it, not unless you build a program that will require one of the newer versions of the Windows C runtime library. That's why libiberty's strnlen is being compiled in the MinGW build in the first place. Specifically, the MinGW headers do provide a prototype for strnlen if the program defines __MSVCRT_VERSION__ to be a high enough version, or defines _POSIX_C_SOURCE >= 200809L, but none of these is set by default, and is not a good idea, as explained above, for a program that needs to run on a wide variety of OS versions. IOW, libiberty shouldn't rely on the system headers to provide a strnlen prototype when libiberty's strnlen is being included in the library as a replacement.