Paul Eggert wrote:
> Despite that disadvantage, it would be a win for users or Gnulib, who
> could stop worrying about the possibility that O_CLOEXEC == 0. I
> installed the attached patch to try to implement this. I don't use
> MS-Windows, though, and may well have missed something.
Looks quit
Thanks for pointing out the problem; I guess I was subconsciously hoping
that platforms lacking O_CLOEXEC were no longer a practical issue. But
that was silly.
On 08/14/2017 10:18 AM, Bruno Haible wrote:
Alternatively, define O_CLOEXEC to a non-zero value on those platforms
that don't support
Hi Paul,
> (opendirat, diropen): Use O_CLOEXEC instead of set_cloexec_flag.
There are platforms which support O_CLOEXEC; on these platforms this commit
is an improvement (eliminate uncontrolled inheritance of fd if another thread
calls fork+exec()).
There are also platforms which don't support O
* lib/fts.c [!_LIBC]: Do not include dirent--.h, unistd--.h, cloexec.h.
(opendirat, diropen): Use O_CLOEXEC instead of set_cloexec_flag.
(fts_build): Use F_DUPD_CLOEXEC rinstad of set_cloexec_flag.
(fd_ring_check): Set cloexec flag on new file descriptors.
(fts_build, fd_ring_check): While we’re at
