> Cc: 42...@debbugs.gnu.org, "Peder O. Klingenberg" <pe...@klingenberg.no>,
> Gnulib bugs <bug-gnulib@gnu.org>
> From: Paul Eggert <egg...@cs.ucla.edu>
> Date: Sun, 28 Jun 2020 13:34:36 -0700
>
> As I understand it the basic issue here is that we want O_CLOEXEC support even
> on platforms that lack it, and we don't want all the calling software to play
> games with "#ifdef O_CLOEXEC" and the like.
AFAICT, O_CLOEXEC is already supported by the 'open' implementation we
use on MS-Windows ('sys_open' in w32.c), so I think we are good there.
> I attempted to work around this particular problem by installing the attached
> workaround into Gnulib and updating Emacs accordingly. Please give it a try.
Thanks, it builds fine.
> Perhaps this should be fixed more systematically in Gnulib instead of worked
> around, but I suppose that might entail some merging between Emacs's and
> Gnulib's ways of dealing with file names under MS-Windows and I'll leave it to
> the MS-Windows experts to figure out how to do that, or whether they want to
> do
> it at all.
As long as config.h is included in a Gnulib source file that calls
'open' (and AFAIK all Gnulib files do that), the call will be
redirected to 'sys_open' mentioned above, and everything is supposed
to "just work".
