tmpnam behaviour on subsequent calls

[Lars Uffmann]

Hi everyone!

I was wondring if the behaviour of cstdio's tmpnam is defined to produce
a different filename on two calls in a row even if the first filename
has not yet been used to create a file.

The documentation at
http://www.cplusplus.com/reference/clibrary/cstdio/tmpnam.html
makes no mention of the behaviour, but down at the example it says "This
program will generate two different names for temporary files." even
though no file is being actually created.

Anyone familiar with the way this function works?

Best Regards,

Lars

 

[Jensen Somers]

Hello,

Hi everyone!

I was wondring if the behaviour of cstdio's tmpnam is defined to produce
a different filename on two calls in a row even if the first filename
has not yet been used to create a file.

The documentation at
http://www.cplusplus.com/reference/clibrary/cstdio/tmpnam.html
makes no mention of the behaviour, but down at the example it says "This
program will generate two different names for temporary files." even
though no file is being actually created.

Anyone familiar with the way this function works?

Best Regards,

Lars

The tmpnam() function shall generate a string that is a valid filename
and that is not the same as the name of an existing file. The function
is potentially capable of generating {TMP_MAX} different strings, but
any or all of them may already be in use by existing files and thus not
be suitable return values.

The tmpnam() function generates a different string each time it is
called from the same process, up to {TMP_MAX} times. If it is called
more than {TMP_MAX} times, the behavior is implementation-defined.

The implementation shall behave as if no function defined in this volume
of IEEE Std 1003.1-2001, except tempnam(), calls tmpnam().

Source: http://www.opengroup.org/onlinepubs/000095399/functions/tmpnam.html

I only have experience using this function in C, where I had to move to
tempnam() because tmpnam() was causing portability issues towards
Windows Vista (LUA related stuff). Although, nowadays I noticed GCC
returns a warning message saying that the use of mkstemp() is advised.

- Jensen

 

[Erik Wikström]

Hi everyone!

I was wondring if the behaviour of cstdio's tmpnam is defined to produce
a different filename on two calls in a row even if the first filename
has not yet been used to create a file.

The documentation at
http://www.cplusplus.com/reference/clibrary/cstdio/tmpnam.html
makes no mention of the behaviour, but down at the example it says "This
program will generate two different names for temporary files." even
though no file is being actually created.

Anyone familiar with the way this function works?

The C99 standard, 7.19.4.4 §3: "The tmpnam function generates a
different string each time it is called." By the way, questions about
functions in the C standard library will usually be better answered in
comp.lang.c.

 

[Lars Uffmann]

The C99 standard, 7.19.4.4 §3: "The tmpnam function generates a
different string each time it is called."

Thank you!

By the way, questions about functions in the C standard library will usually be better answered in
comp.lang.c.

My bad - I thought maybe there was some C++ equivalent, as people keep
pointing out that C and C++ are two different languages (I still see C++
as elaborated on a C basis).

Best Regards,

Lars

 

[Lars Uffmann]

I only have experience using this function in C, where I had to move to
tempnam() because tmpnam() was causing portability issues towards
Windows Vista (LUA related stuff). Although, nowadays I noticed GCC
returns a warning message saying that the use of mkstemp() is advised.

Thank you - tempnam() suits my purpose much better. If mkstemp() is
advised, that is understandable in general (according to documentation),
but is there any way to use ofstream with the integer file descriptor
returned by mkstemp? Doesn't seem like it to me :/

So I guess I'll work with tempnam() for now

Best Regards,

Lars

 

[James Kanze]

Thank you - tempnam() suits my purpose much better. If
mkstemp() is advised, that is understandable in general
(according to documentation), but is there any way to use
ofstream with the integer file descriptor returned by mkstemp?
Doesn't seem like it to me :/

In general, for security reasons, I'd avoid mkstemp, or any
other function which opens the file for you. Generally, you'd
use the return value of tempnam() (which isn't C/C++) or
tmpnam() (which is standard C/C++, but doesn't allow putting the
temporaries in a user specified directory) to create a directory
with restricted access rights (which again requires platform
specific code), and place your temporary files there.

 

[James Kanze]

My bad - I thought maybe there was some C++ equivalent, as
people keep pointing out that C and C++ are two different
languages (I still see C++ as elaborated on a C basis).

tmpnam() is part of C/C++. It's present in standard C++, as
well as standard C, with exactly the same semantics. As such,
it's fully on topic here. But you'll probably find more experts
in it in comp.lang.c.

 

[Greg Herlihy]

In general, for security reasons, I'd avoid mkstemp, or any
other function which opens the file for you.

The fact that mkstemp() creates and opens the file atomically is
precisely what avoids the race condition inherent in first calling
tempnam() to select the file name and then calling another function to
create a file with that name.

< Generally, you'd

use the return value of tempnam() (which isn't C/C++) or
tmpnam() (which is standard C/C++, but doesn't allow putting the
temporaries in a user specified directory) to create a directory
with restricted access rights (which again requires platform
specific code), and place your temporary files there.

The problem of course is finding such a writable directory - and then
ensuring that its contents are deleted before the program exists - in
short, having to deal exactly the kinds of problems that calling
mkstemp() would already solve.

Greg

 

[James Kanze]

The fact that mkstemp() creates and opens the file atomically is
precisely what avoids the race condition inherent in first calling
tempnam() to select the file name and then calling another function to
create a file with that name.

Not according to X/Open, which says simply that "the resulting
name does not duplicate the name of an existing file at the time
of a call to mkstemp()".

mkstemp has many problems, not the least of which, the fact that
it isn't portable. You have no influence over the rights the
file is created with (although from a quality of implementation
point of view, they should be as restrictive as possible). And
of course, anyone who can read the directory where you put the
files can track their creation---it's a small thing, but using a
separate directory prevents even that.

< Generally, you'd

The problem of course is finding such a writable directory - and then
ensuring that its contents are deleted before the program exists - in
short, having to deal exactly the kinds of problems that calling
mkstemp() would already solve.

And how does mkstemp() solve them. Both of those problems are
present with mkstemp. If you only need a single temporary file,
AND portability is not a concern, AND you've verified that your
platform does create the file with restricted rights, then you
probably can get away with using it, but it's not really a very
good general solution. Using a quality implementation of
tmpnam(), then creating a directory, and putting the temporary
files there would be better, but quality implementations of
tmpnam() don't seem to abound: the implementations under Solaris
or Linux are horrible, for example. (Although you're still
better off using tmpnam(), then creating a directory, than using
mkstemp().) tempnam() is better, but again, not portable; I've
ended up writing my own (which only does what a quality
implementation of tmpnam() would do).