From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54041 invoked by alias); 19 May 2017 15:40:32 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 53743 invoked by uid 89); 19 May 2017 15:40:31 -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=unavailable version=3.3.2 spammy= X-HELO: eggs.gnu.org Received: from eggs.gnu.org (HELO eggs.gnu.org) (208.118.235.92) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 19 May 2017 15:40:30 +0000 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dBk11-0008Al-7k for gdb-patches@sourceware.org; Fri, 19 May 2017 11:40:32 -0400 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:58408) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dBk0w-00086z-G2; Fri, 19 May 2017 11:40:26 -0400 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:40: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-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg00454.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.