Re: [PATCH 1/2] fts: fix cloexec races

[Paul Eggert]

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 it, and extend gnulib's open() and openat() wrappers
> to support O_CLOEXEC. But this is more hairy because the platforms could,
> at any time, introduce other O_* flags that happen to collide wit the value
> we happen to pick for O_CLOEXEC.

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.

0001-open-support-O_CLOEXEC.patch
Description: Text Data