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

[Eli Zaretskii <eliz at gnu dot org>]

> From: Tom Tromey <tromey@redhat.com>
> Date: Fri, 05 Dec 2008 17:38:13 -0700
> 
> This patch fixes this problem by introducing new wrapper functions
> which create close-on-exec file descriptors.  Then, these functions
> are used everywhere in gdb.  After this patch, these wrapper functions
> should be used in all new code as well.

Thanks.

>     opsy. gdb /tmp/r
>     [...]
>     (gdb) shell ls -l /proc/$$/fd
>     total 0
>     lrwx------ 1 tromey tromey 64 2008-12-05 17:10 0 -> /dev/pts/1
>     lrwx------ 1 tromey tromey 64 2008-12-05 17:10 1 -> /dev/pts/1
>     lrwx------ 1 tromey tromey 64 2008-12-05 17:10 2 -> /dev/pts/1
>     lr-x------ 1 tromey tromey 64 2008-12-05 17:10 3 -> pipe:[1100229]
>     l-wx------ 1 tromey tromey 64 2008-12-05 17:10 4 -> pipe:[1100229]
>     lr-x------ 1 tromey tromey 64 2008-12-05 17:10 5 -> /proc/8096/fd
> 
> I believe those 'pipe' entries are from the call to pipe in
> linux-nat.c:linux_nat_set_async.

Are you saying that the problem is specific to Linux native targets?
If so, why the solution invades general source files such as remote.c,
ser-tcp.c, ui-file.c, source.c and even remote-mips.c?

> I chose to take advantage of the new glibc flags like O_CLOEXEC when
> they are available.

Relying on glibc is OK for GNU/Linux, but you seem to be modifying
files that have no relation to the Linux native builds.  Does that
mean the non-glibc builds that don't have the support you are relying
on will still leak descriptors?

> +FILE *
> +fopen_cloexec (const char *path, const char *mode)
> +{
> +#ifdef O_CLOEXEC
> +  /* We assume that O_CLOEXEC also implies the availability of the "e"
> +     flag to fopen.  */
> +  char new_mode[20];
> +  strcpy (new_mode, mode);
> +  strcat (new_mode, "e");
> +  return fopen (path, new_mode);

Can we do something more safe than this arbitrary [20] limitation?