Re: [PATCH] fcntl-h: define O_CLOEXEC and O_EXEC if not defined; use new defines

[Eric Blake]

On 09/10/2010 01:13 PM, Jim Meyering wrote:
> Paul Eggert wrote:
> > The motivation for this is that I'm putting GNU tar on a file-descriptor
> > diet, and I needed O_CLOEXEC, which gnulib sometimes doesn't define.
> > It's more convenient for tar if gnulib defines O_CLOEXEC to 0 on platforms
> > that lack it, which is what gnulib already does for the other O_* flags.
> >
> > This patch also adds O_EXEC.  GNU tar doesn't need that, but might as well
> > add it while I'm in the neighborhood.
>
> More convenient for tar, but possible silent inconvenience/bugs
> in gnulib clients.  Any client that does the following may end
> up leaking file descriptors:
>
> #ifdef O_CLOEXEC
> ... expect that O_CLOEXEC works...
> #else
> workaround
> #endif

What's worse, is that since open() does NOT return EINVAL on 
unrecognized flags, you can get into the situation where you have a 
newer glibc but older kernel, where O_CLOEXEC is defined to non-zero by 
the headers but where it _still_ fails to do the right thing.  I'm 
thinking that I really need to devote some time to get my planned 
O_CLOEXEC gnulib support implemented, in order to work around such 
kernel situations (basically, we have to cache the information of 
whether O_CLOEXEC works on the first runtime instance, and use that to 
choose how to handle O_CLOEXEC on all future calls, until such time 
several years down the road when we suspect that the glibc/kernel 
mismatch is no longer an issue in practice).

--
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org