Re: tmpnam(e)

[Paul Hsieh <qed@...>]

> The Lua manual is rather misleading when it says that tmpname() returns a
> file name that can *safely* be used for a temporary file. This is a lie.
> tmpname calls ANSI tmpnam(), which should never be used (at least, not in
> programs that expect to work properly: it's insecure and unsafe).

Of course, since a file *NAME* can never be guaranteed to be unique in a 
multitasking OS; only once the actual file is created can it be known to be unique.  
On the other hand, how do you think things like tmpfile() are created?  In WATCOM 
C/C++ it appears to just call some variation of tmpname() to pick a filename, then 
open and close the filename, then rename() the file, then fopen(*,"wb+") it.  If it 
fails along the way, somewhere it tries again.
 
> Given that there's no ANSI workaround to make tmpnam safe, can I suggest two
> solutions:
> 
> 1. Implement tmpname with tmpnam if there's no other choice, or mkstemp if
> it's available. (Hence, tmpname should actually open a file, not just return
> a name.) This is not perhaps a good solution for Lua, since it involves
> putting in non-ANSI code (even if there's an ANSI alternative) and it still
> exposes Lua scripts running on systems without mkstemp to problems.

It appears as though tmpfile() is an ANSI call.  In WATCOM C/C++ there is no 
mkstemp(), however mktemp() exists and tries to create a unique file from a 
template.  mktemp() doesn't seem particularly universal either since a single 
process instance basically can make at most 26 such files (in DOS) and there is no 
guarantee that these files haven't been created beforehand.  (Maybe WATCOM C/C++'s 
mktemp is not really the same as what mkstemp is in your environment.)
 
> 2. Deprecate tmpname(). Preferably require -DLUA_TMPNAME or somesuch to
> compile it in, so that it's not available by default. This forces Lua
> programmers either to use a system-specific method (such as mkstemp) that is
> known to be safe, or to use some ad-hoc method (e.g. generate their own
> random filename), but *at least they know it's ad-hoc*. Eventually, tmpname
> can be removed.

Well, it seems to me that it would be best to supply a function call that is a best 
replacement of the prior solution.  I.e., use tmpfile().  If that does not exist on 
all systems, then some C compilers implementation of tmpfile() could be used.

--
Paul Hsieh
qed@pobox.com