This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Minor O_CLOEXEC optimization, "regression" fix
- From: Eli Zaretskii <eliz at gnu dot org>
- To: Kai Tietz <ktietz at redhat dot com>
- Cc: jan dot kratochvil at redhat dot com, gdb-patches at sourceware dot org, tromey at redhat dot com
- Date: Wed, 09 Oct 2013 20:07:13 +0300
- Subject: Re: [patch] Minor O_CLOEXEC optimization, "regression" fix
- Authentication-results: sourceware.org; auth=none
- References: <20131008183214 dot GB27355 at host2 dot jankratochvil dot net> <87li23fsym dot fsf at fleche dot redhat dot com> <20131009131016 dot GA1603 at host2 dot jankratochvil dot net> <173490856 dot 4156973 dot 1381325657769 dot JavaMail dot root at redhat dot com>
- Reply-to: Eli Zaretskii <eliz at gnu dot org>
> Date: Wed, 9 Oct 2013 09:34:17 -0400 (EDT)
> From: Kai Tietz <ktietz@redhat.com>
> Cc: gdb-patches@sourceware.org, Tom Tromey <tromey@redhat.com>
>
> > May one rely on MS-Windows fopen("","re") will fail with EINVAL if it fails
> > because of the "e" flag, Kai? It is in GDB function gdb_fopen_cloexec.
>
> Yes, it fails due the 'e' command in mode. Obviously this option isn't supported on Windows due there is no fork.
What does this have to do with fork? Windows does know how to start
child processes, so I think making the handle not inherited is the
proper equivalent on Windows.
Latest runtime libraries have the non-standard 'N' flag.
Alternatively, one can make the handle non-inheritable after opening
the file, by using a Win32 API.
> So yes, probing for EINVAL seems to me like a valid way to probe for valid arguments here.
As I wrote earlier, this is not a good idea, as GDB will likely crash
on latest Windows versions due to invalid parameter handling in the
library.