Re: tmpnam(e)

[Jordan Henderson <jordan@...>]

> 
> > 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.
> 
> There's a difference here: tmpnam *cannot* be used in a secure way in
> general. acos can. Further, most systems allow the floating-point exception
> behaviour to be specified, and C'99 standardises this behaviour.
> 

Hmmm... C99, which almost nobody uses today, standises this behaviour.  So,
anyone who is using floating-point exceptions today is using them in a
non-portable way and shouldn't be using them in conjunction with ANSI
functions, right?  (see below)

> > 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).
> 
> I agree. But features of ISO C such as gets and tmpnam that are inherently
> unsafe should simply not be exposed: they're broken.
> 

Get ISO C to change them then.  lua is a small, easily embedded in a C
program, language, not a Software Engineering Campaign to correct all
that is broken in the world.

> > 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.
> 
> If you're using an ANSI function in a non-portable way, you shouldn't be
> using an ANSI function.
> 

Why is that?  The ANSI function has functionality I require and is well
tested.  Using a function in this way is preferable to writing something
from scratch.

> -- 
> http://sc3d.org/rrt/ | certain, a.  insufficiently analysed
> 

-Jordan Henderson
jordan@greenapple.com