https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70311
--- Comment #2 from Keith Marshall <keith.marshall at mailinator dot com> --- (In reply to Dominique d'Humieres from comment #1) > Could some mingw32 guru assign this PR to her/himself? Well, I should have thought that the requirement to include <strings.h> to expose a prototype for strncasecmp() is more a POSIX.1 conformity issue, than specifically a MinGW issue; you appear to be relying on a non-conformity in glibc, which allows this prototype to be exposed by including <string.h>. MinGW is simply stricter in this aspect of POSIX.1 conformity, so exposing a weakness in your code. It would be inappropriate for you to expect MinGW to become less POSIX.1 conformant, when the correct solution is for you to include the proper header files, at point of use. OTOH, the strnlen() issue is, perhaps, best addressed in MinGW; since the function isn't universally supported by all Windows versions, which MinGW aims to support, it is appropriate for MinGW to provide a suitable fall back.
