TMPFILE(3) NetBSD Library Functions Manual TMPFILE(3)
NAMEtempnam, tmpfile, tmpnam -- temporary file routines
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS#include <stdio.h>FILE *tmpfile(void);
char *tmpnam(char *str);
char *tempnam(const char *tmpdir, const char *prefix);
DESCRIPTION
The tmpfile() function returns a pointer to a stream associated with a
file descriptor returned by the routine mkstemp(3). The created file is
unlinked before 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 `w+'.
The tmpnam() function returns a pointer to a file name, in the P_tmpdir
directory, which did not reference an existing file at some indeterminate
point in the past. P_tmpdir is defined in the include file <stdio.h>.
If the argument s is non-NULL, the file name is copied to the buffer it
references. Otherwise, the file name is copied to a static buffer. In
either case, tmpnam() returns a pointer to the file name.
The buffer referenced by s is expected to be at least L_tmpnam bytes in
length. L_tmpnam is defined in the include file <stdio.h>.
The tempnam() function is similar to tmpnam(), but provides the ability
to specify the directory which will contain the temporary file and the
file name prefix.
The environment variable TMPDIR (if set), the argument tmpdir (if
non-NULL), the directory P_tmpdir, and the directory /tmp are tried, in
the listed order, as directories in which to store the temporary file.
The argument prefix, if non-NULL, is used to specify a file name prefix,
which will be the first part of the created file name. tempnam() allo-
cates memory in which to store the file name; the returned pointer may be
used as a subsequent argument to free(3).
RETURN VALUES
The tmpfile() function returns a pointer to an open file stream on suc-
cess, and a NULL pointer on error.
The tmpnam() and tempnam() functions return a pointer to a file name on
success, and a NULL pointer on error.
ERRORS
The tmpfile() function may fail and set the global variable errno for any
of the errors specified for the library functions fdopen(3) or
mkstemp(3).
The tmpnam() function may fail and set errno for any of the errors speci-
fied for the library function mktemp(3).
The tempnam() function may fail and set errno for any of the errors spec-
ified for the library functions malloc(3) or mktemp(3).
SEE ALSOmkstemp(3), mktemp(3)STANDARDS
The tmpfile() and tmpnam() functions conform to ANSI X3.159-1989
(``ANSI C89''). All described functions also conform to IEEE Std
1003.1-2001 (``POSIX.1''), albeit the tempnam() and tmpnam() functions
have been marked as obsolete in the IEEE Std 1003.1-2008 (``POSIX.1'')
revision.
BUGS
These interfaces are provided for AT&T System V UNIX and ANSI compatibil-
ity only. The mkstemp(3) interface is strongly preferred.
SECURITY CONSIDERATIONS
There are four important problems with these interfaces (as well as with
the historic mktemp(3) interface). First, there is an obvious race
between file name selection and file creation and deletion: the program
is typically written to call tmpnam(), tempnam(), or mktemp(3). Subse-
quently, the program calls open(2) or fopen(3) and erroneously opens a
file (or symbolic link, or fifo or other device) that the attacker has
placed in the expected file location. Hence mkstemp(3) is recommended,
since it atomically creates the file.
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 AT&T System V UNIX implementations of these
functions (and of mktemp(3)) use the access(2) system call to determine
whether or not the temporary file may be created. This has obvious rami-
fications 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.
This implementation of tmpfile() does not have these flaws, and that of
tmpnam() and tempnam() only have the first limitation, but portable soft-
ware cannot depend on that. In particular, the 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.
A link-time warning will be issued if tmpnam() or tempnam() is used, and
advises the use of mkstemp() instead.
NetBSD 8.0 April 30, 2010 NetBSD 8.0

You can also request any man page by name and (optionally) by section:

Command:

Section:

Architecture:

Collection:

Use the DEFAULT collection to view manual pages
for third-party software.