Re: RFA: close-on-exec internal file descriptors

[Tom Tromey <tromey@redhat.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