Re: MinGW compilation warnings in libiberty's xstrndup.c

[Eli Zaretskii <eliz@gnu.org>]

> Cc: gdb-patches@sourceware.org, Thomas Schwinge <thomas@codesourcery.com>
> From: Pedro Alves <palves@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.