4.4BSD/usr/share/man/cat3/tmpfile.0

TMPFILE(3)                  BSD Programmer's Manual                 TMPFILE(3)

NNAAMMEE
     tteemmppnnaamm, ttmmppffiillee, ttmmppnnaamm - temporary file routines

SSYYNNOOPPSSIISS
     ##iinncclluuddee <<ssttddiioo..hh>>

     _F_I_L_E _*
     ttmmppffiillee(_v_o_i_d);

     _c_h_a_r _*
     ttmmppnnaamm(_c_h_a_r _*_s_t_r);

     _c_h_a_r _*
     tteemmppnnaamm(_c_o_n_s_t _c_h_a_r _*_t_m_p_d_i_r, _c_o_n_s_t _c_h_a_r _*_p_r_e_f_i_x);

DDEESSCCRRIIPPTTIIOONN
     The ttmmppffiillee() function returns a pointer to a stream associated with a
     file descriptor returned by the routine mkstemp(3).  The created file is
     unlinked before ttmmppffiillee() 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 ttmmppnnaamm() 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 <_s_t_d_i_o_._h>. If
     the argument _s is non-NULL, the file name is copied to the buffer it ref-
     erences.  Otherwise, the file name is copied to a static buffer.  In ei-
     ther case, ttmmppnnaamm() 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 <_s_t_d_i_o_._h>.

     The tteemmppnnaamm() function is similar to ttmmppnnaamm(), 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 _d_i_r (if non-NULL),
     the directory P_tmpdir, and the directory _/_t_m_p are tried, in the listed
     order, as directories in which to store the temporary file.

     The argument _p_r_e_f_i_x, if non-NULL, is used to specify a file name prefix,
     which will be the first part of the created file name.  TTeemmppnnaamm() allo-
     cates memory in which to store the file name; the returned pointer may be
     used as a subsequent argument to free(3).

RREETTUURRNN VVAALLUUEESS
     The ttmmppffiillee() function returns a pointer to an open file stream on suc-
     cess, and a NULL pointer on error.

     The ttmmppnnaamm() and tteemmppffiillee() functions return a pointer to a file name on
     success, and a NULL pointer on error.

EERRRROORRSS
     The ttmmppffiillee() function may fail and set the global variable _e_r_r_n_o for any
     of the errors specified for the library functions fdopen(3) or
     mkstemp(3).

     The ttmmppnnaamm() function may fail and set _e_r_r_n_o for any of the errors speci-
     fied for the library function mktemp(3).

     The tteemmppnnaamm() function may fail and set _e_r_r_n_o for any of the errors spec-
     ified for the library functions malloc(3) or mktemp(3).

SSEEEE AALLSSOO
     mkstemp(3),  mktemp(3)

SSTTAANNDDAARRDDSS
     The ttmmppffiillee() and ttmmppnnaamm() functions conform to ANSI C X3.159-1989
     (``ANSI C '').

BBUUGGSS
     These interfaces are provided for System V and ANSI compatibility only.
     The mkstemp(3) interface is strongly preferred.

     There are four important problems with these interfaces (as well as with
     the historic mktemp(3) interface).  First, there is an obvious race be-
     tween file name selection and file creation and deletion.  Second, most
     historic implementations provide only a limited number of possible tempo-
     rary file names (usually 26) before file names will start being recycled.
     Third, the System V implementations of these functions (and of mktemp)
     use the access(2) function to determine whether or not the temporary file
     may be created.  This has obvious ramifications for setuid or setgid pro-
     grams, complicating the portable use of these interfaces in such pro-
     grams.  Finally, there is no specification of the permissions with which
     the temporary files are created.

     This implementation does not have these flaws, but portable software can-
     not depend on that.  In particular, the ttmmppffiillee() 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.

4.4BSD                           June 4, 1993                                2