> Fair enough. The man page seems a bit over strong, how about this? > > Index: mktemp.3 > =================================================================== > RCS file: /cvs/src/lib/libc/stdio/mktemp.3,v > retrieving revision 1.45 > diff -u -p -r1.45 mktemp.3 > --- mktemp.3 27 Dec 2010 21:18:44 -0000 1.45 > +++ mktemp.3 7 Jan 2011 20:23:00 -0000 > @@ -72,12 +72,12 @@ does not actually create the temporary f > opportunity during which another process can open the file instead. > Because of this race condition, > .Fn mktemp > -should not be used in new code. > +should not be used where > +.Fn mkstemp > +can be used instead.
That looks good. > .Fn mktemp > was marked as a legacy interface in > -.St -p1003.1-2001 > -and may be removed in a future release of > -.Ox . > +.St -p1003.1-2001 . That looks good too. I think that whoever wrote that saw smoking something. So there is a mkdtemp(), but where is the AF_UNIX version? I think it is important that people who do use mktemp(3) realize that they must loop over failure (creating a new path each time), and they need to use a "do not use the path from elsewhere unless the code that opens it returns success" paradigm. mktemp(3) just provides a "potentially unique name"; the expected gaurantees must be supplied by the caller.
