This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Thursday 22 March 2012 16:02:31 D. V. Wiebe wrote: > * 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? you could fchdir(dir) first if the side effects aren't a problem. but there probably should be a mkstempat() func ... > * 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? the __wur probably should be dropped since POSIX too says that it always returns template. as for the code, misc/mktemp.c in the latest git looks fine to me. it says "null string" and not "null pointer". -mike
Attachment:
signature.asc
Description: This is a digitally signed message part.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |