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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: gdb-patches@sourceware.org
> From: Tom Tromey <tromey@redhat.com>
> Reply-To: Tom Tromey <tromey@redhat.com>
> Date: Sat, 06 Dec 2008 08:58:03 -0700
> 
> 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.

It seemed to me that the patch assumes too much about the various
#define's -- which is OK if you are targeting glibc, but may need
refinement for other libc's.  But perhaps I missed something; I will
take another look.

> >> +  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.

I just don't like relying on "is never longer than N" assumptions, and
GNU coding standards frown on arbitrarily dimensioned arrays, so...