The reason that mkstemp is used rather than tmpfile, is that many
systems have a bad race condition in tmpfile. At least that's what
I was told (I got the code from the bugtrac's mailing list).
Ah. Darn. Well, maybe the configure process could check to see if
mkstemp() exists and use tmpfile() if it doesn't?
What's the race condition?
I'll attach the comments by Casper Diks of Sun, about the problem.
Richard Coleman
coleman(_at_)math(_dot_)gatech(_dot_)edu
Typical system V implementations (as well as older BSD implementations) have
an unsafe tmpfile(). This is true for Solaris (before 2.6 when we fixed it)
and in IRIX (last time I looked). Perhaps we can check and compile a list?
Here's one I did and it also uses temporary files, but it uses
"mkstemp()" which should be save.
BTW, mkstemp() always uses open(,, 0600) so you get private tmpfiles;
tmpfile() is required to use the umask() in setting the mode. Depending
on how this is implemented, there's a window in which a tmpfile() can be opened
by other processes.
A naive reimplementation of tmpfile() using mkstemp() fails the standard
conformance tests. (s = mkstemp(template); unlink(template); return
fdopen(s,"w+)). Solaris 2.6 does use mkstemp() but does an fchmod() after
unlink()ing the file so there's no race condition either.
Standard are stupid sometimes.