From: Pedro Alves <palves@redhat.com>
To: Pierre Muller <pierre.muller@ics-cnrs.unistra.fr>
Cc: "'Tom Tromey'" <tromey@redhat.com>,
"'Eli Zaretskii'" <eliz@gnu.org>,
gdb-patches@sourceware.org
Subject: Re: [RFA-v2] Avoid invalid parameter warnings in C runtime function for mingw built GDB
Date: Wed, 14 Aug 2013 12:01:00 -0000 [thread overview]
Message-ID: <520B719B.3020904@redhat.com> (raw)
In-Reply-To: <520b6c37.e9e6440a.7cfb.45fcSMTPIN_ADDED_BROKEN@mx.google.com>
On 08/14/2013 12:38 PM, Pierre Muller wrote:
> Is this OK to commit?
> Maybe some comments on the ChangeLog entry?
> * common/filestuff.c (gdb_fopen_cloexec): Do not try to use "e"
> mode if operating system doesn't know O_CLOEXEC, this allows to
> avoid getting a output debug string warning for mingw hosted
> GDB executables.
This comment should really be in the sources instead. That here you'd
have:
* common/filestuff.c (gdb_fopen_cloexec): Do not try to use "e"
mode if operating system doesn't know O_CLOEXEC.
and in the source, where you have:
> + /* If O_CLOEXEC is zero, the operating system doesn't
> + know about close on exec mode "e", so don't even try to use it. */
> + static int fopen_e_ever_failed = O_CLOEXEC == 0;
I suggest:
/* Probe for "e" support once. But, if we can tell the operating
system doesn't know about close on exec mode "e" without probing,
skip it. E.g., the Windows runtime issues an "Invalid parameter
passed to C runtime function" OutputDebugString warning for
unknown modes. Assume that if O_CLOEXEC is zero, then "e" isn't
supported. */
static int fopen_e_ever_failed;
--
Pedro Alves
next prev parent reply other threads:[~2013-08-14 12:01 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <"002201ce9414$7e0d7130$7a285390$@muller"@ics-cnrs.unistra.fr>
2013-08-09 14:09 ` [RFC] Avoid invalid parameter warnings in C runtime function for mingw builtr GDB Eli Zaretskii
2013-08-13 9:13 ` Pierre Muller
[not found] ` <41630.7793967009$1376385245@news.gmane.org>
2013-08-13 15:37 ` Tom Tromey
2013-08-14 11:38 ` [RFA-v2] Avoid invalid parameter warnings in C runtime function for mingw built GDB Pierre Muller
[not found] ` <520b6c37.e9e6440a.7cfb.45fcSMTPIN_ADDED_BROKEN@mx.google.com>
2013-08-14 12:01 ` Pedro Alves [this message]
2013-08-14 12:12 ` [RFA-v3] " Pierre Muller
2013-09-13 22:35 ` Pierre Muller
[not found] ` <5233934f.8360440a.1d3e.ffffa937SMTPIN_ADDED_BROKEN@mx.google.com>
2013-09-13 23:08 ` Doug Evans
2013-09-14 6:30 ` Pierre Muller
[not found] ` <"001401ce9805$6cce7050$466b50f0$@muller"@ics-cnrs.unistra.fr>
2013-08-13 16:35 ` [RFC] Avoid invalid parameter warnings in C runtime function for mingw builtr GDB Eli Zaretskii
2013-08-08 8:51 Pierre Muller
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=520B719B.3020904@redhat.com \
--to=palves@redhat.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=pierre.muller@ics-cnrs.unistra.fr \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox