From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27567 invoked by alias); 13 Aug 2013 09:13:56 -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 27555 invoked by uid 89); 13 Aug 2013 09:13:55 -0000 X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,MSGID_MULTIPLE_AT autolearn=no version=3.3.2 Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.201.47) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 13 Aug 2013 09:13:54 +0000 Received: from md14.u-strasbg.fr (md14.u-strasbg.fr [130.79.200.249]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r7D9Do46018373 ; Tue, 13 Aug 2013 11:13:50 +0200 (CEST) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from ms13.u-strasbg.fr (ms13.u-strasbg.fr [130.79.204.113]) by md14.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id r7D9DoNk030887 ; Tue, 13 Aug 2013 11:13:50 +0200 Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (Authenticated sender: mullerp) by ms13.u-strasbg.fr (Postfix) with ESMTPSA id 1E6151FD84; Tue, 13 Aug 2013 11:13:49 +0200 (CEST) From: "Pierre Muller" To: "'Eli Zaretskii'" Cc: References: <"002201ce9414$7e0d7130$7a285390$@muller"@ics-cnrs.unistra.fr> <83bo57rm59.fsf@gnu.org> In-Reply-To: <83bo57rm59.fsf@gnu.org> Subject: RE: [RFC] Avoid invalid parameter warnings in C runtime function for mingw builtr GDB Date: Tue, 13 Aug 2013 09:13:00 -0000 Message-ID: <001401ce9805$6cce7050$466b50f0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2013-08/txt/msg00334.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Eli Zaretskii > Envoy=E9=A0: vendredi 9 ao=FBt 2013 16:10 > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFC] Avoid invalid parameter warnings in C runtime function for > mingw builtr GDB >=20 > > From: "Pierre Muller" > > Date: Thu, 8 Aug 2013 10:51:37 +0200 > > > > Lately I got several warnings with mingw built > > GDB's: > > > > warning: Invalid parameter passed to C runtime function. > > > > Use the new "set stop-on-debug-string-event on" > > command submitted previously in > > http://sourceware.org/ml/gdb-patches/2013-08/msg00236.html > > > > I was able to trace this down to > > the fopen call with mode that to "re". > > As stated in the source, the "e" mode is a glibc extension > > about close on exec which generates this warning. > > > > The patch below excludes this code if __MINGW32__ is defined, > > but maybe it should be excluded if O_CLOEXEC is zero? >=20 > Actually, if we want this to be portable, we should have a function to > make a file handle be non-inheritable, instead of relying on glibc > extensions. There _is_ a way to make a file handle non-inheritable on > Windows. >=20 > > diff -u -p -r1.7 filestuff.c > > --- src/gdb/common/filestuff.c 26 Jun 2013 08:01:55 -0000 1.7 > > +++ src/gdb/common/filestuff.c 7 Aug 2013 12:35:55 -0000 > > @@ -311,6 +311,7 @@ FILE * > > gdb_fopen_cloexec (const char *filename, const char *opentype) > > { > > FILE *result =3D NULL; > > +#ifndef __MINGW32__ > > static int fopen_e_ever_failed; > > > > if (!fopen_e_ever_failed) > > @@ -320,17 +321,21 @@ gdb_fopen_cloexec (const char *filename, > > copy =3D alloca (strlen (opentype) + 2); > > strcpy (copy, opentype); > > /* This is a glibc extension but we try it unconditionally on > > - this path. */ > > + this path, except when using Windows OS msvcrt dll, > > + in order to avoid a output debug string event. */ > > strcat (copy, "e"); > > result =3D fopen (filename, copy); > > } > > +#endif > > > > if (result =3D=3D NULL) > > { > > /* Fallback. */ > > result =3D fopen (filename, opentype); > > +#ifndef __MINGW32__ > > if (result !=3D NULL) > > fopen_e_ever_failed =3D 1; > > +#endif > > } > > > > if (result !=3D NULL) >=20 > Wouldn't it be better to instead initialize fopen_e_ever_failed to 1 > on MinGW? Then the rest of the code will "just work", no? Once again, my insufficient C knowledge is to blame... Would that be correct? #if O_CLOEXEC static int fopen_e_ever_failed =3D 0; #else static int fopen_e_ever_failed =3D 1; #endif But then the variable name is not appropriate anymore... In fact, when I tried to read the code around that function, I discovered that there is already another variable called trust_o_cloexec It seems to me that both are testing the same glibc extension, trust_o_cloexec as it numeric form O_CLOEXEC and fopen_e_ever_failed as its string mode equivalent "e". Is it really possible that trust_o_cloexec and fopen_e_ever_failed do not match? Should a unique variable be enough? Concerning my original RFC, should I resubmit it with the above suggestion? Pierre Muller =20=20 =20