Ben Pfaff <[EMAIL PROTECTED]> writes: > 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.
Eric Blake mentioned some of the problems, but to my mind the biggest problem with tmpfile is that implementations typically unlink the file immediately after creating it, which means that a long-running process that uses tmpfile can exhaust /tmp even though "ls -l /tmp" doesn't see anything amiss. This can be a real denial-of-service problem (usually inadvertent). A superuser can figure it out with lsof or the equivalent, but ordinary users can easily be flummoxed. There are a few segfaultish problems which people don't often run into. I just now scanned the glibc code and discovered that it mishandles the case of setting TMPDIR to a string that is 4 GiB long "/tmp/./././././...." on a 64-bit host. (If you have the energy perhaps you can get this bug fixed in glibc.) But this sort of problem often occurs in the "safer" temporary-file primitives as well.
