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: Kai Tietz <ktietz at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: gdb-patches at sourceware dot org, Tom Tromey <tromey at redhat dot com>
- Date: Wed, 9 Oct 2013 09:34:17 -0400 (EDT)
- 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>
----- Original Message -----
> On Tue, 08 Oct 2013 21:44:33 +0200, Tom Tromey wrote:
> > >>>>> "Jan" == Jan Kratochvil <jan.kratochvil@redhat.com> writes:
> > Jan> - if (result == NULL)
> > Jan> + if (result != NULL)
> > Jan> + fopen_e_ever_succeeded = 1;
> > Jan> + else if (!fopen_e_ever_succeeded)
> >
> > What if we have it check for EINVAL instead?
>
> 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. The allowed options for mode-flag is dependent to runtime-version. The function (it is under the hood the _openfile routine, which handles this) returns EINVAL on any not supported mode-options. So yes, probing for EINVAL seems to me like a valid way to probe for valid arguments here.
> original post:
> [patch] Minor O_CLOEXEC optimization, "regression" fix
> https://sourceware.org/ml/gdb-patches/2013-10/msg00233.html
>
>
> Thanks,
> Jan
>
Regards,
Kai