This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: RFA: close-on-exec internal file descriptors
- From: Tom Tromey <tromey at redhat dot com>
- To: Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb-patches at sourceware dot org
- Date: Sat, 06 Dec 2008 08:58:03 -0700
- Subject: Re: RFA: close-on-exec internal file descriptors
- References: <m3skp2w32i.fsf@fleche.redhat.com> <umyf9n2la.fsf@gnu.org>
- Reply-to: Tom Tromey <tromey at redhat dot com>
>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
>> I believe those 'pipe' entries are from the call to pipe in
>> linux-nat.c:linux_nat_set_async.
Eli> Are you saying that the problem is specific to Linux native targets?
No. That was an example.
>> I chose to take advantage of the new glibc flags like O_CLOEXEC when
>> they are available.
Eli> Relying on glibc is OK for GNU/Linux, but you seem to be modifying
Eli> files that have no relation to the Linux native builds. Does that
Eli> mean the non-glibc builds that don't have the support you are relying
Eli> on will still leak descriptors?
No. In each case, if O_CLOEXEC is not available, we fall back to the
fcntl-based method. That is what the calls to "close_on_exec" do in
the patch.
>> + char new_mode[20];
>> + strcpy (new_mode, mode);
>> + strcat (new_mode, "e");
>> + return fopen (path, new_mode);
Eli> Can we do something more safe than this arbitrary [20] limitation?
I don't think there is any point, because the mode argument to fopen
is never longer than 4 characters or so. However, if you really want
this, I will change it to a malloc.
Tom