mkstemp

[Stephen Weeks]

> I guess that I would have split mkstemp in a different way.  I see 2 distinct
> parts to mkstemp:
>     Generate a temporary file name.
>     Create and open the file if it doesn't exist.
> Thus I would make one function which, given a string, adds on a random suffix
> to it.  Now mkstemp would call this function, do the createf, and
>     If it worked, return the string and the file.
>     If it failed because of EEXIST, loop.
>     If it fails for another reason, raise the exception.
> 
> Given  that,  I  wouldn't  bother  writing  a mkstemps function except in the
> source to MLton.  There mkstemps would take just the args you specified.   It
> would generate the tmp file name from the prefix, concatenate the suffix, and
> do the createf and looping itself.

I think it is silly to duplicate that looping code in both places.  It is
nontrivial (after all, I screwed it up the first time with EEXISTS).

Actually, I am currently exporting the tempName generator in addition to mkstemp
and mkstemps.  To expose the looping, I would be willing to export something
like
	val findTemp: (unit -> string) -> string * outstream
which repeatedly generates a string and tries to open it until it succeeds.

> The point is that the notion of a library function to create temporary  files
> with  a  given  prefix and suffix just isn't generally useful.  It is used in
> MLton only because gcc looks at the suffix, but I have never seen  any  other
> place  where it would be useful.  Exporting the generation of temporary names
> is good enough for me.

Oh well, it's just an extra function and there is some independent evidence of
its usefulness given its existence in OpenBSD.