Re: request tmpfile(3) wrapping in Guile 1.9 libguile

[Ken Raeburn]

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