From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51758 invoked by alias); 19 May 2017 15:40:26 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 51067 invoked by uid 89); 19 May 2017 15:40:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=iow X-HELO: fencepost.gnu.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (208.118.235.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 15:40:24 +0000 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4169 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1dBk0v-0007cT-HB; Fri, 19 May 2017 11:40:25 -0400 Date: Fri, 19 May 2017 15:47:00 -0000 Message-Id: <83a8683ler.fsf@gnu.org> From: Eli Zaretskii To: Pedro Alves CC: gcc-patches@gcc.gnu.org, gdb-patches@sourceware.org, thomas@codesourcery.com In-reply-to: <60a354b0-6c1a-15ea-177a-8bdb198c8c03@redhat.com> (message from Pedro Alves on Fri, 19 May 2017 16:22:55 +0100) Subject: Re: MinGW compilation warnings in libiberty's xstrndup.c Reply-to: Eli Zaretskii References: <83h90vcqo6.fsf@gnu.org> <60a354b0-6c1a-15ea-177a-8bdb198c8c03@redhat.com> X-SW-Source: 2017-05/txt/msg01587.txt.bz2 > Cc: gdb-patches@sourceware.org, Thomas Schwinge > From: Pedro Alves > Date: Fri, 19 May 2017 16:22:55 +0100 > > But then, xstrndup.c has at the top: > > #ifdef HAVE_STRING_H > #include > #else > # ifdef HAVE_STRINGS_H > # include > # 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.