|
From: | Paul Eggert |
Subject: | Re: [PATCH 1/2] fts: fix cloexec races |
Date: | Mon, 14 Aug 2017 13:10:09 -0700 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 |
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
[Prev in Thread] | Current Thread | [Next in Thread] |