bug#15015: Fix some minor races in hosts lacking mkostemp

[Eli Zaretskii <eliz@gnu.org>]

> Date: Sat, 03 Aug 2013 14:26:20 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: 15015@debbugs.gnu.org
> 
> On 08/03/2013 07:55 AM, Eli Zaretskii wrote:
> 
> > gettimeofday, open, and lstat are implemented by Emacs in w32.c.  At
> > lest the last 2 are not equivalent to what gnulib uses.
> 
> The lack of equivalence shouldn't matter.  The lstat call
> (though it is compiled) won't be used by Emacs's use of the
> mkostemp module on Microsoft platforms, so it's OK.  
> mkostemp always calls 'open' with O_CREAT | O_EXCL; in that
> case sys_open is just a simple wrapper around _open, so that
> should be OK too.  And gettimeofday, as you mentioned, isn't
> a problem.

I think sys_open also sets the no-inherit flag, so it's not just a
wrapper.

In any case, even if you are right (and I don't have enough resources
at the moment to verify that), reusing most of the code of sys_mktemp
to implement mkostemp seems like a safer bet, since that code is
already well tested by years of usage.  This also has the nice benefit
of not breaking the old configure.bat build.

So I went ahead and implemented mkostemp for MS-Windows (trunk
revision 113687).  I also removed sys_mktemp, as it is no longer
needed.

> >> Presumably nt/configure.bat and makefile-w32.in could be updated
> >> to compile the new files.  This sort of thing should be routine,
> >> if that avenue is still supported.
> >
> > This "support" needs volunteers, which didn't yet show up.
> 
> If nobody's supporting it, then it's not really supported.

That's true, but I'd like to avoid breaking it for as long as is
feasible, to let people adapt.

> > We can always install the gnulib stuff for those other platforms
> 
> Yes, that's a given.  We need to do that, to fix the race
> condition bugs in OS X, Solaris, etc.

Please go ahead.

> > and work around it on Windows.
> 
> I'm trying to help save work in the Windows port, by having
> Windows Emacs use Gnulib mkostemp (which will be in the
> source code anyway) the same way it's being used on OS X etc.
> If this approach is feasible, it should save us all some
> work; if not, it should be easy for a Windows expert to work
> around any problems in w32.c and/or msdos.c.

This approach is generally feasible, and I appreciate your efforts.
It's just that in this case having a Windows-specific implementation
was easy.

(Don't worry about msdos.c, I will fix that when I have time.  There
can be no race conditions on MSDOS anyway...)

Thanks.