Re: split stdio-safer into fopen-safer, tmpfile-safer

[Ben Pfaff]

Eric Blake <address@hidden> 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: address@hidden
web: http://benpfaff.org