bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#28023: fix make-temp-file race on local host


From: Eli Zaretskii
Subject: bug#28023: fix make-temp-file race on local host
Date: Wed, 09 Aug 2017 19:05:16 +0300

> From: Paul Eggert <eggert@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?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]