From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18202 invoked by alias); 13 Aug 2013 15:37:43 -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 18193 invoked by uid 89); 13 Aug 2013 15:37:42 -0000 X-Spam-SWARE-Status: No, score=-7.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 15:37:42 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r7DFbaU5007315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 13 Aug 2013 11:37:36 -0400 Received: from barimba (ovpn-113-91.phx2.redhat.com [10.3.113.91]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r7DFbYo9023021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 13 Aug 2013 11:37:35 -0400 From: Tom Tromey To: "Pierre Muller" Cc: "'Eli Zaretskii'" , Subject: Re: [RFC] Avoid invalid parameter warnings in C runtime function for mingw builtr GDB References: <"002201ce9414$7e0d7130$7a285390$@muller"@ics-cnrs.unistra.fr> <83bo57rm59.fsf@gnu.org> <41630.7793967009$1376385245@news.gmane.org> Date: Tue, 13 Aug 2013 15:37:00 -0000 In-Reply-To: <41630.7793967009$1376385245@news.gmane.org> (Pierre Muller's message of "Tue, 13 Aug 2013 11:13:49 +0200") Message-ID: <874natr48x.fsf@fleche.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SW-Source: 2013-08/txt/msg00347.txt.bz2 >>>>> "Pierre" == Pierre Muller writes: Pierre> Once again, my insufficient C knowledge is to blame... Pierre> Would that be correct? Pierre> #if O_CLOEXEC Pierre> static int fopen_e_ever_failed = 0; Pierre> #else Pierre> static int fopen_e_ever_failed = 1; Pierre> #endif O_CLOEXEC is unconditionally defined earlier. But you can just write: /* If we provide a fake O_CLOEXEC, then don't ever try "e". */ static int fopen_e_ever_failed = O_CLOEXEC == 0; Pierre> But then the variable name is not appropriate anymore... You can rename it if you want, but I don't really care either way. Pierre> In fact, when I tried to read the code around that function, I Pierre> discovered that there is already another variable called Pierre> trust_o_cloexec Pierre> It seems to me that both are testing the same glibc extension, Pierre> trust_o_cloexec as it numeric form O_CLOEXEC Pierre> and fopen_e_ever_failed as its string mode equivalent "e". Pierre> Is it really possible that trust_o_cloexec and fopen_e_ever_failed Pierre> do not match? I forget exactly why I did this. Maybe I was just being overly cautious. Pierre> Should a unique variable be enough? Maybe. Tom