On Feb 8, 2010, at 06:11, Andy Wingo wrote: > 1. tmpfile(3) returns a FILE*, whereas Guile's fports normally deal in > file descriptors. Will this be a problem? What about buffering? Do we > have to fclose() the FILE* to get deletion working?
On POSIX systems you can use fileno(). The automatic deletion is probably handled by unlinking the file before returning the file handle. But you probably can't get rid of the FILE* without calling fclose(), which would throw away the file and file descriptor. On most UNIX systems you could probably dup() the file descriptor indicated by fileno() and then fclose() the FILE* handle, without losing the on-disk temporary file storage. I don't know if you can use fileno on Windows. It's also not clear to me from a quick look at the MSDN docs on tmpfile() whether the temporary file gets deleted if your program changes directories while running. > 2. Why return 'tmpfile as the name, and not whatever filename one can > get from the FILE* ? If the file has been unlinked, the file name isn't going to be useful. In fact, the tmpfile() interface doesn't give you a filename. > 3. Is tmpfile(3) really needed, if you have mkstemp! and dynamic > extents? Here's what I use, for example: But mkstemp doesn't guarantee that no one else will grab the file name in between the time mkstemp checks that the file doesn't exist, and when you actually open(O_CREAT) it. Using it can leave you with a race condition such that you need to loop generating and then trying filenames; tmpfile hides that away from the implementation, at least, or maybe uses more randomness in its filenames than mkstemp supports. (And if you don't use O_EXCL, you may have a security problem, too.) > (unwind-protect > (proc template) > (delete-file template)))) Interesting... A temp-file port type could probably be created that either uses tmpfile or unlinks on close or destruction of the port object, couldn't it? I don't know if that would be better or worse than using tmpfile directly. Does the unwind-protect here catch any cases that that would miss? Ken
