Talk:Tmpfile

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia

Removal of dubious section about supposed security vulnerabilities[edit]

I have removed the following content from the article:

Security Issues
The tmpfile function is susceptible to a number of security vulnerabilities[dubious – discuss]; the UNIX function mkstemp, which performs a similar function, is less vulnerable to attack.

The reason is that I see no mention of security vulnerabilities in tmpfile in any of these places:

The function tmpfile is present in the standards SVr4, 4.3BSD, C89, C99, SUSv2, POSIX.1-2001. Broken functions like gets are not present in all these standards. -- Jorge Peixoto (talk) 02:30, 26 July 2008 (UTC)[reply]

I also removed the link http://www.owasp.org/index.php/Insecure_Temporary_File . I don't know about the credibility of this content. -- Jorge Peixoto (talk) 04:56, 26 July 2008 (UTC)[reply]

Security is indeed an issue with the tmpfile function. These security issues are further documented here:
I have added these sources to the article. ← Michael Safyan (talk) 07:37, 27 July 2008 (UTC)[reply]
These links deal mostly with functions like tmpnam and tempnam, that return a char *.
tmpfile, in turn, is only insecure if it is badly implemented. For example, the OpenBSD implementation uses mkstemp internally. It seems that the insecure implementation being referred to in the articles comes from (guess!) MS Windows. There is an important difference between a function with a flawed interface - like gets - that is inherently unsafe, and a function with a reasonable interface - like tmpfile - that may present security concerns if it was implemented by an incompetent programmer.
If you want to add these links to the article, please point what operating system is affected by them, and whether the issues have been solved.
This Wikipedia article should not advise against the use of tmpfile, which is the only safe ISO C function for temporary file creation. -- Jorge Peixoto (talk) 15:14, 27 July 2008 (UTC)[reply]
Actually, like gets, the tmpfile function is inherently unsafe. This is because there is no means of specifying the permissions to be associated with the newly created temporary file. While some implementations are more secure than others, there is no way to portably rely on it. Certainly a programmer who sees this article as a reference or to find out about this function for the first time deserves this heads up. Therefore, I ask that you do not delete this material. Also, there are other issues with the material you have changed, so please do not revert. Thank you. Have a good day. ← Michael Safyan (talk) 20:41, 27 July 2008 (UTC)[reply]
The gets interface makes it impossible to implement it as a safe function, because the interface itself is flawed. The tmpfile interface, on the other hand, is reasonable. The function may be unsafe if it is implemented by a drunk baboon. We could mention security issues for a good portion of the standard C functions if we think "well, once, some vendor managed to f*ck up with this function. So I will add a security warning even without knowing whether he has already fixed or which vendor it was". I would like you to point out which OS was affected by the issues, and whether they are still valid (which I doubt). Without this, mentioning security issues in the article will only confuse programmers. This is the only safe ISO C function for temporary file creation. -- Jorge Peixoto (talk) 21:16, 27 July 2008 (UTC)[reply]
Do a little reading (you'd be surprised who you're making disparaging comments about ;-) Tedickey (talk) 21:22, 27 July 2008 (UTC) indentation later edited[reply]
Tell me. And, are you talking to who (the indentation makes it seem you are talking to Michael Safyan)? -- Jorge Peixoto (talk) 21:52, 27 July 2008 (UTC)[reply]
Although I agree that it's unclear who is talking about what hereabouts, nonetheless, *YOU* did revert at least one change by Tedickey, and that is enough for me to tell you: he meant what he said, when he told you "Do a little reading (you'd be surprised who you're making disparaging comments about ;-)"
You see, although I don't think his name is especially famous, nor do I know him personally, and probably have never spoken/written to him, he maintains software that is IMHO in sharply wider use than e.g. Linux itself, and if I introduced him as a keynote speaker to pretty much any general Unix or Linux conference, referencing what he has been doing for Lo, These Many Years, I guarantee he would get a standing ovation.
That doesn't mean that he is automatically right and gets the last word on whatever he edits on wikipedia -- quite the contrary, he is just another contributer like the rest of us -- but it *does* make *you* look clueless to revert him casually and edit-war with him casually, because those of us who have been doing Unix systems programming for *decades* will be quite interested to hear your arguments -- and if they are absent, well...
*Anyway*, he's not just mouthing off. Do find out who he is (in the sense of, what has he been doing for the community for many, many years, and what does that say about his expertise).
P.S. Yes, that all potentially applies to Michael Safyan, too, but Michael has IMHO been vastly more NPOV and vastly more humble and vastly more "let's get stuff done positively".
Dougmerritt (talk) 04:15, 1 August 2008 (UTC)[reply]
First, I am astonished that anyone could agree with the behavior of Tedickey here. After all this, I would be pleased to meet Michael (pitty he seems to live some 8000 kilometers away). Tedickey's behavior was opposite to that of Michael.
Second, the naive, grossly wrong commentary he wrote in Talk:Tmpfile#Spurious_comment_about_reentrancy makes me suspect that he should study a lot more before attempting to write a Unix program
Third, he said "you'd be surprised who you're making disparaging comments about". I was commenting about whoever implemented the unsafe tmpfile. Since not even Michael knows which current OS has an unsafe tmpfile, it would take a huge amount of work for me to
  1. Find out which OS is involved
  2. Find out who implemented tmpfile for that OS
I thus asked "tell me", with the reply "Do your own reading", followed by some rude messages both in this talk page and in my talk page. That is hardly adult behavior and served only to harm the discussion, right after I attempted to focus my concerns. -- Jorge Peixoto (talk) 04:58, 1 August 2008 (UTC)[reply]
I see. Well, you said "Any Unix implementation of tmpfile is probably reentrant", which is an astonishing statement that leaves you open to a number of kinds of disparagement. The GNU C library was in *general* not reentrant for many, many years, just to pick one really easy example. As for the rest, we all seem to agree that Michael's behavior here has been more than reasonable, but for some reason that I don't understand (e.g. he's right, you need to educate yourself, not ask him to educate you) you object to Tedickey's behavior here.
Whatever; that's a side-issue, compared with him clearly knowing this and related topics *vastly* better than your own ill-informed speculations, given which you've got brass balls to come out with your most recent piece of rudeness to him: "makes me suspect that he should study a lot more before attempting to write a Unix program".
I tell you again, you're just making yourself out to be an idiot by making statements like that about him. Not that ad hominems are relevant to wikipedia discussions in the first place, but you are *really*, *really* off-track in how badly mistaken you are here.
As to the topic itself, quite obviously the general topic is infamously associated with security problems, so I really don't think that anyone could possibly be on strong ground in feeling that they have proof that one particular function is inherently safe, or would be if not implemented by baboons -- those are stupid statements. So are claims that standards and libraries are in general safe because they exclude the infamous "gets" -- do you really think that things like strcpy() and sprintf() and scanf() are really that much safer than gets()? (Hint: they're not.) Dougmerritt (talk) 15:07, 1 August 2008 (UTC)[reply]
  1. Regarding "Any Unix implementation of tmpfile is probably reentrant", that was just a top-of-the-head hunch, as I admittedly don't know enough about Unix to say that with confidence. In fact, to say that with confidence, one needs a long beard and knowledge of many Unix implementations, including inner workings. And precisely for this reason I did not say that in the main article. If you see that conversation, I was justifying why I wrote in the article that "GNU tmpfile is reentrant" which is obviously too system-specific. It was precisely because I don't know if other implementations are reentrant, and the only objective thing I can say is that GNU tmpfile is reentrant.
  2. I didn't mean that tmpfile is undoubtedly safe. I meant it has no inherent reason (that we currently know of) to be unsafe. It is not like gets. For example, OpenBSD's tmpfile uses mkstmp internally. tmpfile can be implemented in an unsafe manner, but so can mkstemp.
  3. Please don't put words in my mouth. I did not say a standard is safe just because it excludes gets. I just said that a function that is present in a truckload of standards, and is not considered problematic in its Opengroup specification or in the documentation of major OSs, is less likely to be unsafe like gets.
  4. strcpy, sprintf and scanf are now unsafe? Just because someone can write strcpy($buffer_of_unknown_size, $possibly_big_string) ? My concept of safety (for a function) is that it doesn't generate bugs when properly used. gets is unsafe, while strcpy is safe. If you want a language that doesn't allow you to shoot your own feet, that is not C.
  5. You still don't you realize the error in his commentary? The eyes of a Unix programmer hurt when reading that

The referenced GNU library documentation doesn't provide any substance to the statement, which should have been qualified to note where the necessary state is stored (probably in an atexit, which leads to further problems).

The guy thinks that to implement tmpfile one is obligated to explicitly store a state, with an atexit being an appropriate place for it. I showed him the source of GNU tmpfile, and he still couldn't believe he was wrong. Well, studies have showed that incompetent people are generally unaware of it: www.apa.org/journals/features/psp7761121.pdf
I was discussing normally with Michael until Tedickey came around. He wasn't even interested in the technical discussion.
Let me point out that I normally am not like this. I have never been this flamey before. I got pissed off with the guy's rudeness. In the future I will probably just ignore it. -- Jorge Peixoto (talk) 17:29, 1 August 2008 (UTC)[reply]
← Unindent

Hi, everyone. I thought I might make a brief comment here. While I appreciate the kind comments and support from Dougmerritt and Tedickey, I would like to point out that my disagreement with Jorge Peixoto has been entirely civil and I would appreciate it even more if everyone were to stop arguing. Also, I would like to point out that there is a difference between reentrancy and thread safety. The requirement for reentrancy is more strict than the requirement for thread safety; all reentrant functions are thread safe, but not necessarily the reverse. It is more likely for implementations to be thread safe than to be reentrant. ← Michael Safyan (talk) 19:35, 1 August 2008 (UTC)[reply]

That was very constructive and civil of you, so of course I (and, apparently, the others) instantly heeded your request.
Now that some months have passed, I wonder if you and Jorge Peixoto, having apparently buried the hatchet, might agree that almost all of this Talk page could be archived as largely obsolete, and replaced with whatever summary the two of you find appropriate?
I'm suggesting that because the current state of this page, and what is the state of consensus or lack thereof, seems somewhat unclear to me, and I would think would be totally opaque to some poor newbie wandering in here.
Another way to put it: either you guys have achieved consensus, and can summarize, or if that's not the case, then your plea for the peanut gallery to quiet down was out of line; see what I mean?
Thanks, Dougmerritt (talk) 05:20, 7 November 2008 (UTC)[reply]
Yes, we reached consensus; we compromised on a shorter, less noticeable version of the security vulnerabilities section. Per WP:TALK and per WP:Refactoring talk pages, it would probably be best to archive this page, rather than to delete and summarize its contents. I see no urgency in archiving this page, since it is relatively short, neither do I object to archiving at this time. ← Michael Safyan (talk) 00:56, 10 November 2008 (UTC)[reply]
I'm in no hurry, I just wanted to make sure that the appropriate action was *eventually* taken. I'll leave it as a word to the wise, then. Dougmerritt (talk) 19:55, 10 November 2008 (UTC)[reply]

Spurious comment about reentrancy[edit]

The comment doesn't belong in the main section (certainly not in a single paragraph which attempts to describe the function) - perhaps in some as-yet unwritten section on portability. The referenced GNU library documentation doesn't provide any substance to the statement, which should have been qualified to note where the necessary state is stored (probably in an atexit, which leads to further problems). Tedickey (talk) 20:17, 27 July 2008 (UTC)[reply]

The referenced GNU library documentation doesn't provide any substance to the statement

Are you joking? In case you aren't, read the source.
FILE *
tmpfile (void)
{
  char buf[FILENAME_MAX];
  int fd;
  FILE *f;

  if (__path_search (buf, FILENAME_MAX, NULL, "tmpf", 0))
    return NULL;
  fd = __gen_tempname (buf, GEN_THIS);
  if (fd < 0)
    return NULL;

  /* Note that this relies on the Unix semantics that
     a file is not really removed until it is closed.  */
  (void) __unlink (buf);

  if ((f = __fdopen (fd, "w+b")) == NULL)
    __close (fd);

  return f;
}
About whether or not this belongs in the article, programmers are supposed to know whether the function is reentrant. Any Unix implementation of tmpfile is probably reentrant, but I cannot use such imprecise words in the article. This is why I added the objective statement that GNU tmpfile is reentrant, and I hope some contributor in the future will find documentation stating that other Unix tmpfiles are reentrant. About other systems (like MS Windows), I don't know if their tmpfile is reentrant. --Jorge Peixoto (talk) 23:02, 27 July 2008 (UTC)[reply]
The topic mentions POSIX (not Linux). Do some reading (bye). Tedickey (talk) 23:08, 27 July 2008 (UTC)[reply]


Edit war discussion[edit]

Per this diff (and similar diffs):

JorgePeixoto, let's discuss this a bit, and maybe we can come to an agreement.
Introduction

Firstly, I prefer to start with "The ISO C/POSIX function..." rather than "tmpfile", simply because it is awkward to begin a sentence with a lowercase word. Secondly, if we were to adopt your version, the "a" before "ISO" should become an "an". Also, I think it flows better to say what the function does, not what it is "designed to" do. While it is fine to, in a sentence, state which header file contains the function declaration, it makes users have to search a bit. If the header file is separated into its own "Inclusion" section, it is easier for readers to use the article as a reference. Also, whereas one version now has inline citations, the other version presently lacks such citations.
Michael Safyan (talk) 01:41, 28 July 2008 (UTC)[reply]

Regarding the misuse of the article "a", I can only say "oops, sorry".
About the rest, I disagree. I believe Wikipedia articles should begin with a sentence like "Subject is a description". One example is "A spoon is a utensil consisting of a small (...)". Regarding the "designed to", I think it is better than saying "The ISO C/POSIX function tmpfile allows C/C++ programmers to create (...)" because the former is more precise. fopen also "allows" programmers to create temporary files, but wasn't specifically designed for it. Inspired by the malloc article, I propose
In [[computing]], <code>'''tmpfile'''</code> is an [[ISO C]]/[[POSIX]] function for creating [[temporary file]]s (...)
About the "Inclusion" section, I believe it is not encyclopedic, and we should not do the user's homework for him. And I did not understand what is the challenge on the user's part to, after reading that the function is declared in stdio.h, realize that the proper include directive is #include <stdio.h. That is one of the most basic aspects of C programming.
About the citations, I found them unnecessary because the article is very small, and the references themselves are also small, making it easy to verify the article. But, per your request, I will provide citations next time. -- Jorge Peixoto (talk) 04:17, 28 July 2008 (UTC)[reply]
Ok. Well, we found several things we agree on. I very much like your latest proposal for the intro section. Thank you for acquiescing to my preference for listing the include directives. Obviously, C and C++ programmers should know how to include header files; I simply wanted the inclusions to be easy to spot, for those readers who would use the article as a quick reference. ← Michael Safyan (talk) 04:51, 28 July 2008 (UTC)[reply]
Description

Is it really necessary to have a description section? Shouldn't the lead paragraph explain what the function does? Perhaps such a section should be renamed to "Details", "Detailed description", etc. Just a thought.
Michael Safyan (talk) 01:41, 28 July 2008 (UTC)[reply]

I knew "Description" was not ideal, but I did not come up with anything better. Among your two suggestions, I prefer "Detailed description". Do you think it would be ideal? -- Jorge Peixoto (talk) 01:59, 28 July 2008 (UTC)[reply]
Personally, I would just put that information into the lead paragraph. However, if you think the information belongs in a separate section, then "Detailed description" is fine. ← Michael Safyan (talk) 04:51, 28 July 2008 (UTC)[reply]
Security issues

I am not sure why you insist on removing this information. I have provided several sources, demonstrating that there are security issues. I suppose I could find more, if you really like. However, when a government certified agency, such as Build Security In, says there are potential security issues, I would think that would be enough. In any event, it is Wikipedia policy that verifiable and reliably sourced material is not removed without good cause. If you strongly feel that the material should be removed, then the onus is on you to find equally verifiable and reliably sourced information disputing the statement that there are potential security issues.
Michael Safyan (talk) 01:41, 28 July 2008 (UTC)[reply]

I only disputed disputed the credibility of http://www.owasp.org/index.php/Insecure_Temporary_File. I did not dispute the credibility of the other sources.
My concern is that the sources you provided focus on functions like tmpnam that return a char *, and only vaguely mention tmpfile. It is not clear what is the problem with tmpfile.
There is nothing wrong with its interface.
What some of your sources do mention is that some implementations have implemented tmpfile very poorly. They don't explain which implementations had this bug and when it was solved. I strongly disagree that we should confuse programmers by saying "tmpfile is insecure" because some unnamed vendor managed to f*ck it up in the past. We don't know if any widely used OS has a flawed tmpfile. I would like to know
  1. Which OS had a flawed tmpfile?
  2. And more importantly: is the issue still valid (which I doubt)?

Ok. Before I discuss this matter, I would like to make clear the limitations of my knowledge. I am presently an undergraduate computer engineering student. I am no expert in computer security. What I write is based solely on information gathered from peers and from various programming newsgroups. Ok. Now, as I understand it, several variants of UNIX -- which ones, specifically, I do not know -- are susceptible for the following reason: most implementations of tmpfile rely on the unlink function to unlink the file immediately after it is created. This results in the file having only one reference -- the file stream reported by tmpfile --, and when that stream is closed, there are no references remaining, and the underlying file is deleted. However, on some implementations, unlinking the file also means that the filename no longer appears to be in use. This means that if two programs call tmpfile at about the same time, they may both select the same file name and both may think that it is no longer in use. Under this race condition, it is possible for one program to overwrite the temporary file of the other. As I understand it, this is not the only vulnerability related to tmpfile on UNIX systems and that there are also vulnerabilities on Windows. When it comes down to it, I rely on sources which are qualified in this matter. The government certified organization "Build Security In" says it is unsafe, Richard Lewis who is a Software Security Consultant says it is unsafe, etc. As per Wikipedia policy, we go by the sources, not by whatever the editors may think. And while I understand your objection that the function signature might not be unsafe in theory, computer programming is a field of practice and, in practice, it isn't safe -- at least not according to the sources. ← Michael Safyan (talk) 05:09, 28 July 2008 (UTC)[reply]

Most of your sources don't focus on tmpfile. Those that do are https://www.securecoding.cert.org/confluence/display/seccode/VOID+FI039-C.+Create+temporary+files+securely
and
http://www.codeproject.com/KB/web-security/TemporaryFileSecurity.aspx
The last one is written by Richard Lewis, who is a "Software Security Consultant", but doesn't specify his employer or where he graduated. Quite suspicious. I think we should remove this source. The previous securecoding.cert.org is much better.
But even the securecoding.cert.org source did not point what OS had these flaws (other than the dinosauric AT&T System V and other "historic implementations").
About your possible scenario of tmpfile vulnerability: the natural way for a Unix system to open a temporary file is with open ($PATH, O_RDWR | O_CREAT | O_EXCL, S_IRUSR | S_IWUSR). O_RDWR means "open for reading and writing". O_CREAT | O_EXCL mean "If O_CREAT and O_EXCL are set, open() shall fail if the file exists. The check for the existence of the file and the creation of the file if it does not exist shall be atomic with respect to other threads executing open() naming the same filename in the same directory with O_EXCL and O_CREAT set."
I don't know OpenGroup's other threads includes other threads from different processes, so your scenario is possible if the particular OS implements open such that the above check is non-atomic when multiple processess are involved. But this would affect both tmpfile and mkstemp. Some ancient OS might have implemented tmpfile without the O_CREAT | O_EXCL flags being passed to open, but they would correct it after the multiple reports of security vulnerability. Unless we are talking of an ancient OS not in wide use (as I suspect).
Let me re-state my concerns, so we can focus this huge discussion:
  1. There is no inherent reason for mkstemp to be safe and tmpfile be unsafe - at least the mkstemp specification from opengroup does not provide safety: it does not even mention permissions or filename unpredictability; the only additional guarantee for mkstemp is that the filename is unique.
  2. It seems that the unsafe tmpfile implementations were from some ancient OS
  3. Yes, some credible sources talk about security vulnerabilities and mention tmpfile. But they often mention tmpfile only vaguely, and none of them have said that any widely used OS provides a flawed tmpfile implementation
If the Security issues section is to remain, it has to be reworded. Something like "Some particular vendors have provided unsafe implementations of tmpfile. The Posix function mkstemp is typically implemented more safely, but is not standard C. —Preceding unsigned comment added by JorgePeixoto (talk • contribs)
I disagree with that rewording. Firstly, mkstemp is not POSIX. POSIX, as most programmers use the term, refers to IEEE Std 1003.1, 1988. The function mkstemp is defined in IEEE Std 1003.1, 2004. It was only recently moved from "unistd.h" to "stdlib.h". On my system, it is still necessary to include "unistd.h". Secondly, it is not necessary to say that mkstemp "is not standard C"; whereas tmpfile is described as an "ISO C/POSIX" function, mkstemp was described as an "UNIX" function. Furthermore, if it were standard C, it would -- or at least should -- be available on Windows; however, as the security section made quite clear, the function is not available on Windows. In addition, users may find out that it is not standard C using the mkstemp wikilink; the "#include <unistd.h>" is a pretty big giveaway. Secondly, "some particular" is redundant (isn't "some" sufficient?), and it is also unsourced. For all we know, "many" or "most" vendors do not implement the function securely. Maybe "few" do, although that is probably not the case, since otherwise there would not be such a brouhaha... unless, maybe "few, albeit prominent, vendors" implement it insecurely. Whatever the case may be, Wikipedia's core tenet is verifiability. The current material in the section is verifiability, what you propose to add is not.
Regarding the source from The Code Project. It sounds to me like you are using the fact that Richard Lewis lives in India as an excuse to discard the source. Please keep in mind that 1.) the post corroborates information already stated by the government certified security organizations "Build Security In" and "CERT", and 2.) articles on The Code Project generally go through moderation. Also, a consultant usually does not have an employer; while some consultants work in a consultancy firm, many consultants are self-employed. They temporarily hire themselves out to whichever company has need of their expertise. That CERT and Build Security In (yes, the Build Security In source implicated "tmpfile", not just "tmpname") did not list any particular OS's is entirely irrelevant. These organizations are reliable sources, and it is sufficient that they say the function is insecure. While it would be nice if they were to supply a laundry list of platforms on which they detected the vulnerability, it is not necessary from Wikipedia's standpoint. I think that we should find an extra set of heads to get an outside perspective on this matter. I am going to request opinions on this matter, and I will provide the message I have left to these individual's on their talkpages. ← Michael Safyan (talk) 15:48, 30 July 2008 (UTC)[reply]
Return value

While the explanation is more or less on target, using the word "descriptor" makes the explanation more -- not less -- confusing, ... especially, since the type of FILE is not necessarily opaque. Also, I think that we should either list all the values of errno which the function can set on failure or not mention errno at all. It does not make sense, IMHO, to casually mention errno and then not satisfy the reader's curiosity.
Michael Safyan (talk) 01:41, 28 July 2008 (UTC)[reply]

Regarding "stream descriptor", how about "stream pointer" then?
I disagree on the need to "supply all possible errno values or nothing". One reason is that knowing about the specific error condition is often unnecessary. It is convenient to code like this:
  FILE *mytmpfile = tmpfile();
  if (!mytmpfile)
    err(1, "Failed to create temporary file");
To use the err function, the user must know that, on failure, tmpfile sets errno (which is used by err to append a specific error message to the generic message provided by the user), but does not need to know about every possible errno value (which are system-dependent, as far as I know). So we may or may not include all possible errno values, but I think we should mention errno in either case. -- Jorge Peixoto (talk) 02:54, 28 July 2008 (UTC)[reply]
Where is err defined? I do not see an "err" function in my man pages. Did you mean perror? ← Michael Safyan (talk) 05:19, 28 July 2008 (UTC)[reply]
I see the err function mentioned in the errx man page. errx is a "sister" function. Read about these functions; they are very nice. They allow you to provide error messages in a nice standard style. They are also very easy and convenient.
err(EXIT_FAILURE, "Failed to create temporary file") prints to stderr a message like this:
program_name: Failed to create temporary file: Permission denied
And then exits with status EXIT_FAILURE
program_name is the program invocation name, and Permission denied is the error message from errno.
If you were to duplicate this with calls to perror and exit, it would take some work. Specially because an error message is supposed to contain the program invocation name (1). Where would you get this from? argv[0] is only easily accessible from within main. If you are writing a hypothetical frobnicate_the_bar function, which is supposed to be reusable in multiple programs, the only way to print a nice error message (which includes the program invocation name) is to use a function like err. Unfortunately, these functions are from BSD (also available in GNU Libc) and are not standard POSIX.
Note 1: Non-interactive programs include the program invocation name in their error messages:
rm /dev
rm: cannot remove `/dev': Is a directory
-- Jorge Peixoto (talk) 06:32, 28 July 2008 (UTC)[reply]
Ok. Thank you for the information. I probably would not have come across the function, otherwise. Most of the programming I do is cross-platform stuff, so I would not ordinarily use it. Actually, I don't usually use perror either; typically, I use a switch statement and then throw an exception based on the value of errno. I think it would be useful to inform readers of the potential values of errno in the event of failure, so I have added that content. I hope you don't mind. Thank you again for sharing the information about err, it is always good to learn something new. ;-) ← Michael Safyan (talk) 22:39, 28 July 2008 (UTC)[reply]
Reentrancy

I am not sure why this is even mentioned. The resources which have been allocated with tmpfile are returned from the function and must be deallocated with a call to fclose. Therefore, there is no reason to suspect that invocations to tmpfile share resources. Also, unless there are sources which say that certain implementations are not reentrant, it is weird to say that a particular implementation is, implying -- or at least suggesting -- that others are not.
Michael Safyan (talk) 01:41, 28 July 2008 (UTC)[reply]

The temporary file created by tmpfile is deleted automatically when it is closed or when the program terminates. A novice programmer might think that tmpfile uses "some special logic" to do this, which could possibly make it non-reentrant. Indeed, this may be the case on certain systems. It is not an issue on a Unix-like system, which can implement tmpfile by opening a file and then unlinking it. The operating system then automatically removes the file when it is closed.
Regarding the fact that I only mentioned GNU tmpfile, the reason is that I only know about the reentrancy of GNU tmpfile. I don't know about tmpfile's reentrancy on other systems. I hope that future contributors will add additional information, with proper sources, so we can say that "All major Unix implementations of tmpfile, along with the implementation of MS Windows, are reentrant" or "All major Unix implementations of tmpfile are reentrant, but not the MS Windows implementation", whichever is true. In the meanwhile, I believe it is useful to state that GNU tmpfile is reentrant
  1. As a pratical information about programming GNU systems
  2. As a reminder that the programmer should check the documentation of his particular system before relying on a function's reentrancy —Preceding unsigned comment added by JorgePeixoto (talk • contribs)

Actually, I take back what I said about reentrancy. It would not surprise me if all or most implementations were thread safe, it would surprise me, though, -- considering the random generation of the file name and considering that the tmpfile function takes no parameters for storing that information -- if there were any implementation which were reentrant. Anyway, I think more sources should be found before anything is said of the matter.
Michael Safyan (talk) 05:38, 28 July 2008 (UTC)[reply]

Reason for this article?[edit]

I saw that on the WP:3O page, though I won't comment on the "edit war" itself. Frankly, I'm astonished that this page even exists... how on earth is an article on a single POSIX function justified? I mean, this is supposed to be an encyclopaedia, not a POSIX manual and I can't imagine how this would ever pass the notability requirements. I'm kind of tempted to ask for speedy deletion... Averell (talk) 14:00, 31 July 2008 (UTC)[reply]

In contrast to Gummi Bears, or Helm Hammerhand, to point out two topics which you have improved Tedickey (talk) 14:30, 31 July 2008 (UTC)[reply]
No, we certainly don't want Wikipedia to become an UNIX manual. If you look at WP:WikiProject C++, you will see a list of existing as well as requested articles. While there are articles devoted to each standard ISO C and ISO C++ header file, there are only articles or article requests for a handful of individual functions. The other functions are grouped with their respective headers or omitted. ← Michael Safyan (talk) 14:49, 31 July 2008 (UTC)[reply]
I'm certainly not saying that C++ shouldn't be discussed. But what makes this function so special that it deserves it's own article? I don't see anything special about it... and there are even 3 (!) articles on different tempfile-making functions, plus one on the content itself. Averell (talk) 08:06, 1 August 2008 (UTC)[reply]
This article is in fact invaluable, in that it discusses the noun "tmpfile", whereas some other people think that only the verbs in APIs should be discussed. There is no reason to prefer either verbs or nouns in wikipedia articles; they are generally dual to each other (in the mathematical sense of "dual").
The issue of noun-primary versus verb-primary versus both-equal is infamous in the CHI (Computer-Human Interface) literature, but not so well known to systems programmers and kernel hackers, but nonetheless, personal preference for one or the other is no kind of NPOV.
I must also say that I prefer the "include lots of useful info" approach to wikipedia over the infamously-popular "exclude everything that can't be proven to meet the current guidelines" approach. Dougmerritt (talk) 03:23, 1 August 2008 (UTC)[reply]
I don't see how the notability of a subject is related to whether the article discusses a noun or a verb... Averell (talk) 08:10, 1 August 2008 (UTC)[reply]

Third opinion[edit]

In my opinion, this article should be deleted. This is a single, non-notable, non-controversial unix function. It fails WP:N and WP:NOTGUIDE. With respect to the argument about the security section, I think if this article survives a deletion proposal, then it's appropriate for a security note to exist, but not as the first subheading. The argument above tells me that it should be enough to reduce the security paragraph to a single sentence with an acceptable source, and incorporate that with something else. ~Amatulić (talk) 16:06, 31 July 2008 (UTC) I concur. --Yecril (talk) 08:45, 16 November 2009 (UTC)[reply]

Caveat: access denied[edit]

The function is pretty useless as implemented in MSVCRT. It fails with "Access denied" on the following conditions, all of them quite typical:

  1. The current drive corresponds to rights-managed volume, e.g. NTFS.
  2. Ordinary users are not allowed to create files in the root directory.
  3. The calling process does not run with power user privileges.

--Yecril (talk) 08:51, 16 November 2009 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Talk:Tmpfile&oldid=1202850408"