This is the mail archive of the
mailing list for the glibc project.
Re: tmpnam v mkstemp
- To: Neale dot Ferguson at softwareAG-usa dot com
- Subject: Re: tmpnam v mkstemp
- From: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Date: Sat, 11 Nov 2000 13:55:25 -0800 (PST)
- cc: libc-alpha at sources dot redhat dot com
On Sat, 11 Nov 2000 Neale.Ferguson@softwareAG-usa.com wrote:
> Date: Sat, 11 Nov 2000 16:21:43 +0200
> From: Neale.Ferguson@softwareAG-usa.com
> To: email@example.com
> Subject: tmpnam v mkstemp
> What is the nature of the warning issued:
> xxxxxxxxx.so: the use of `tmpnam' is dangerous, better use `mkstemp'
Several reasons. Firstly, if the function's argument is null, it uses a and
returns a pointer to a static buffer, which is not thread safe. Secondly, it
does not guarantee that a file which has the generated filename does not
actually exist, only that it did not exist at some time in the past. If you
open this file for writing, you may clobber the temporary file created by
another program that is running concurrently.
Although tmpnam is an ANSI C function, working around this problem has
no portable ANSI C solution, so the function is essentially useless.
mkstemp creates not only the name but it the file itself, and allows the
app to specify a prefix for the name to further reduce the risk of
clashes, and to allow temporary files to be more easily identifiable.
(Nitpick: if your /tmp directory is on NFS, it's possible that mkstmp
implementation based on open/O_EXCL can still break. I don't know how
the glibc mkstemp works currently).