mktemp + openat and related questions
D. V. Wiebe
dvw@phas.ubc.ca
Thu Mar 22 20:02:00 GMT 2012
I have a directory descriptor and a mktemp(3)-style template string.
I'd like to open a temporary file in the directory indicated by the
descriptor. The only way I've found to do this is, essentially:
int MakeTempFile(int dir, char *template)
{
int fd;
char *saved_template = strdup(template);
if (!saved_template)
return -1;
do {
strcpy(template, saved_template);
mktemp(template);
if (template[0] == 0) {
free(saved_template);
return -1;
}
fd = openat(dir, template, O_RDWR | O_CREAT | O_EXCL, 0600);
} while (errno == EEXIST);
free(saved_template);
return fd;
}
I have a couple of questions regarding the use of mktemp(3):
* The linker scolds me for using mktemp(3) and suggests I use mkstemp(3)
instead. I'd be happy to do so but, AFAICT, it's not possible in this
situation (since I don't know the path to the directory and I need to
/at least/ make the temporary file on the same device as the directory
whose descriptor I have). Am I right in disregarding this warning?
* The compiler scolds me for not checking the return value of mktemp(3),
but the mktemp(3) manual page says mktemp() always returns its input
(and sets it to the empty string on error). This seems to jibe with
my reading of the mktemp() implementation in glibc-2.14.1.
Am I right in concluding that the __wur attribute on this function
declaration in stdlib.h (and the accompanying comment "Returns
TEMPLATE, or a null pointer if it cannot get a unique file name" in
that header) is incorrect and can be disregarded?
TIA,
-dvw
--
Don Wiebe dvw@phas.ubc.ca
Department of Physics and Astronomy
University of British Columbia Hennings 204
6224 Agricultural Road Tele: +1-604-822-2585
University Endowment Lands, BC
Canada V6T 1Z1 http://ketiltrout.net/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-help/attachments/20120322/14854bad/attachment.sig>
More information about the Libc-help
mailing list