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 [email protected] +1-801-349-2682
Libvirt virtualization library http://libvirt.org
