GNU bug report logs - #28023
fix make-temp-file race on local host

Previous Next

Full log

Message #17 received at 28023 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 28023 <at> debbugs.gnu.org
Subject: Re: bug#28023: fix make-temp-file race on local host
Date: Wed, 09 Aug 2017 19:05:16 +0300

> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Tue, 8 Aug 2017 22:38:05 -0700
> 
> I plan to install the attached patch in master soon, and am sending it for 
> review to bug-gnu-emacs first in case there's some problem with it on 
> MS-Windows.

Thanks for the heads-up.  Unfortunately, it isn't as simple as we'd
like it to be, because Gnulib doesn't support file names encoded in
UTF-8 (or any other encoding except the current system codepage) on
MS-Windows, while Emacs does.

We could resolve this problem by providing a way for the Windows build
to specify its own replacements for 'open', 'mkdir', and 'lstat'
(Emacs already have such replacements in w32.c), which tempname.c
calls, but that would require minor changes in Gnulib's tempname.c.
Or we could steal the relevant code from tempname.c into a
Windows-specific implementation in w32.c, and refrain from using the
Gnulib version on Windows.  Which way would you prefer to go?  Or
maybe you have yet another idea?

> @@ -1915,9 +1913,7 @@ endif
>  ## begin gnulib module secure_getenv
>  ifeq (,$(OMIT_GNULIB_MODULE_secure_getenv))
>  
> -ifneq (,$(gl_GNULIB_ENABLED_secure_getenv))
>  
> -endif
>  EXTRA_DIST += secure_getenv.c

This seems to say that we will sometimes use secure_getenv, but the
relevant code in tempname.c is conditioned on _LIBC, which AFAIU is
only true when building glibc, so why do we need that?  Or did I miss
something?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.