Re: tmpnam(e)

[David Jones <djones@...>]

In message <Pine.LNX.4.33.0105061707470.2556-100000@localhost.localdomain>, Reu
ben Thomas writes:
> 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).
> 
> 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.
> 
> 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.
> 
> At the very least, a warning should be put in the manual, rather than the
> current assertion that tmpname is safe.

As far as I can tell, the lua tradition seems to be to expose the
functionality of the ISO C libraries without much regard for whether
they are safe or not.  That is, not only are unsafe features exposed (EG
tmpnam and acos), but no attempt is made to make them safe.

acos is another example: On a system I use lua on, the epxression
"acos(2)" dumps core.

I think this is a desirable state of affairs in that by following this
policy lua inherits the behaviour of the underlying system (for the
alternative see Common Lisp).

tmpnam is not always unsafe, the programmer may be using it in an
embedded system with only one application running.  It would then seem
petty to prevent the programmer from using it.

I would go with your last option.  Put a warning in the manual.

Cheers,
 drj