add ANSI contribution notice

[unix-history] / usr / src / lib / libc / stdio / tmpnam.3

.\" Copyright (c) 1988, 1991 The Regents of the University of California.
.\" All rights reserved.
.\"
.\" This code is derived from software contributed to Berkeley by
.\" the American National Standards Committee X3, on Information
.\" Processing Systems.
.\"
.\" %sccs.include.redist.man%
.\"
.\"     @(#)tmpnam.3	5.14 (Berkeley) %G%
.\"
.Dd 
.Dt TMPFILE 3
.Os
.Sh NAME
.Nm tempnam ,
.Nm tmpfile ,
.Nm tmpnam
.Nd temporary file routines
.Sh SYNOPSIS
.Fd #include <stdio.h>
.Ft FILE *
.Fn tmpfile void
.Ft char *
.Fn tmpnam "char *str"
.Ft char *
.Fn tempnam "const char *tmpdir" "const char *prefix"
.Sh DESCRIPTION
The
.Fn tmpfile
function
returns a pointer to a stream associated with a file descriptor returned
by the routine
.Xr mkstemp 3 .
The created file is unlinked before
.Fn tmpfile
returns, causing the file to be automatically deleted when the last
reference to it is closed.
The file is opened with the access value
.Ql w+ .
.Pp
The
.Fn tmpnam
function
returns a pointer to a file name, in the
.Dv P_tmpdir
directory, which
did not reference an existing file at some indeterminate point in the
past.
.Dv P_tmpdir
is defined in the include file
.Aq Pa stdio.h .
If the argument
.Fa s
is
.Pf non- Dv NULL ,
the file name is copied to the buffer it references.
Otherwise, the file name is copied to a static buffer.
In either case,
.Fn tmpnam
returns a pointer to the file name.
.Pp
The buffer referenced by 
.Fa s
is expected to be at least
.Dv L_tmpnam
bytes in length.
.Dv L_tmpnam
is defined in the include file
.Aq Pa stdio.h .
.Pp
The
.Fn tempnam
function
is similar to
.Fn tmpnam ,
but provides the ability to specify the directory which will
contain the temporary file and the file name prefix.
.Pp
The environment variable
.Ev TMPDIR
(if set), the argument
.Fa dir
(if
.Pf non- Dv NULL ) ,
the directory
.Dv P_tmpdir ,
and the directory
.Pa /tmp
are tried, in the listed order, as directories in which to store the
temporary file.
.Pp
The argument
.Fa prefix ,
if
.Pf non- Dv NULL ,
is used to specify a file name prefix, which will be the
first part of the created file name.
.Fn Tempnam
allocates memory in which to store the file name; the returned pointer
may be used as a subsequent argument to
.Xr free 3 .
.Sh RETURN VALUES
The
.Fn tmpfile
function
returns a pointer to an open file stream on success, and a
.Dv NULL
pointer
on error.
.Pp
The
.Fn tmpnam
and
.Fn tempfile
functions
return a pointer to a file name on success, and a
.Dv NULL
pointer
on error.
.Sh ERRORS
The
.Fn tmpfile
function
may fail and set the global variable
.Va errno
for any of the errors specified for the library functions
.Xr fdopen 3
or
.Xr mkstemp 3 .
.Pp
The
.Fn tmpnam
function
may fail and set
.Va errno
for any of the errors specified for the library function
.Xr mktemp 3 .
.Pp
The
.Fn tempnam
function
may fail and set
.Va errno
for any of the errors specified for the library functions
.Xr malloc 3
or
.Xr mktemp 3 .
.Sh SEE ALSO
.Xr mkstemp 3 ,
.Xr mktemp 3
.Sh STANDARDS
The
.Fn tmpfile
and
.Fn tmpnam
functions
conform to
.St -ansiC .
.Sh BUGS
These interfaces are provided for System V and
.Tn ANSI
compatibility only.
The
.Xr mkstemp 3
interface is strongly preferred.
.Pp
There are four important problems with these interfaces (as well as
with the historic
.Xr mktemp 3
interface).
First, there is an obvious race between file name selection and file
creation and deletion.
Second, most historic implementations provide only a limited number
of possible temporary file names (usually 26) before file names will
start being recycled.
Third, the System V implementations of these functions (and of
.Xr mktemp )
use the
.Xr access 2
function to determine whether or not the temporary file may be created.
This has obvious ramifications for setuid or setgid programs, complicating
the portable use of these interfaces in such programs.
Finally, there is no specification of the permissions with which the
temporary files are created.
.Pp
This implementation does not have these flaws, but portable software
cannot depend on that.
In particular, the
.Fn tmpfile
interface should not be used in software expected to be used on other systems
if there is any possibility that the user does not wish the temporary file to
be publicly readable and writable.