This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [RFC] Avoid invalid parameter warnings in C runtime function for mingw builtr GDB
- From: Tom Tromey <tromey at redhat dot com>
- To: "Pierre Muller" <pierre dot muller at ics-cnrs dot unistra dot fr>
- Cc: "'Eli Zaretskii'" <eliz at gnu dot org>, <gdb-patches at sourceware dot org>
- Date: Tue, 13 Aug 2013 09:37:34 -0600
- Subject: Re: [RFC] Avoid invalid parameter warnings in C runtime function for mingw builtr GDB
- References: <"002201ce9414$7e0d7130$7a285390$ at muller"@ics-cnrs.unistra.fr> <83bo57rm59 dot fsf at gnu dot org> <41630 dot 7793967009$1376385245 at news dot gmane dot org>
>>>>> "Pierre" == Pierre Muller <pierre.muller@ics-cnrs.unistra.fr> 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