Eric Blake <[EMAIL PROTECTED]> writes: > According to Ben Pfaff on 7/25/2006 11:21 AM: >> Can you expand on why tmpfile is not so safe? > > I'd still like to fear Paul's reasons.
I hope you mean "hear" them :-) > But one of mine is that tmpfile is allowed to leave a permanent > file behind if the call to tmpfile() is interrupted, or if the > process _exit()s. Yet there is no way to know what that file > is. At least with mkstemp, you choose the file prefix. Even > though there is a race between the time that you mkstemp() and > unlink(), such that the same problem exists of leaving a > permanent file behind if interrupted at the wrong time, at > least you can document to the user where to look for bogus > files. Another reason is that POSIX allows implementations to > limit you to TMP_MAX tmpfiles, which may be smaller than the > number of open fd's allowed. (Hmm - sounds like an aardvark is > in order, since POSIX still calls out TMP_MAX in the normative > text to tmpnam, but deleted it from limits.h). OK. Those issues are reasonable. I was worried that there was something bigger here. Usually a "safety" issue is something more important than leaving a temporary file undeleted or limiting their number, like the possibility of a security hole, a segfault, etc. -- Ben Pfaff email: [EMAIL PROTECTED] web: http://benpfaff.org
