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/c...io/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

Hello,

Lars Uffmann wrote:
> 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/c...io/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/...ns/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

On 2008-01-18 17:12, Lars Uffmann wrote:
> 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/c...io/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.

--
Erik Wikström

Erik Wikström wrote:
> 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

Jensen Somers wrote:
> 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

On Jan 21, 8:39 am, Lars Uffmann <a...@nurfuerspam.de> wrote:
> Jensen Somers wrote:
> > 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 :/

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 (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jan 21, 8:36 am, Lars Uffmann <a...@nurfuerspam.de> wrote:
> Erik Wikström wrote:
> > 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).

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.

--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34

On Jan 21, 1:35am, James Kanze <james.ka...@gmail.com> wrote:
> On Jan 21, 8:39 am, Lars Uffmann <a...@nurfuerspam.de> wrote:
>
> > Jensen Somers wrote:
> > > 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 :/
>
> 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