TMPFILE(3) | Library Functions Manual | TMPFILE(3)

# NAME

`tempnam`, `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 mode ‘`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`() allocates 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 success, 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 specified for the library function mktemp(3).

The `tempnam`() function may fail and set errno for any of the errors specified for the library functions malloc(3) or mktemp(3).

# SEE ALSO

mkstemp(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 compatibility 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). Subsequently, 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 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.

This implementation of `tmpfile`() does not have these flaws, and that of `tmpnam`() and `tempnam`() only have the first limitation, but portable software 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.

April 30, 2010 | NetBSD 11.0