From: "Ben Davis" Newsgroups: comp.os.msdos.djgpp Subject: Possible bug in libc tmpnam() function Date: Fri, 14 Sep 2001 11:27:15 +0100 Lines: 26 Message-ID: <9nsm2c$q0f$1@news5.svr.pol.co.uk> NNTP-Posting-Host: modem-287.hake.dialup.pol.co.uk X-Trace: news5.svr.pol.co.uk 1000463244 26639 217.134.49.31 (14 Sep 2001 10:27:24 GMT) NNTP-Posting-Date: 14 Sep 2001 10:27:24 GMT X-Complaints-To: abuse AT theplanet DOT net X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Reply-To: djgpp AT delorie DOT com Hi, I wrote a program which reads a large quantity of data from one file and then writes data to another. The output file is chosen using the tmpnam() function, to be renamed at the end. It is most convenient for me to detect errors by checking if errno is nonzero once at the end of the program. To my dismay, I found ENOENT in the variable by the time my program had finished - and this is after the input file had been opened, since an error at that point would have been output with a different message. A quick debugging session showed that tmpnam() changed the value of errno, yet it filled the string with a valid filename which was later opened successfully. I would presume errno was set when testing for the presence of the file, since tmpnam() does not overwrite existing files. However, it is my understanding that errno should be preserved by all successful library calls. I must admit I am using an old version of DJGPP. However, on the off chance that the bug has not yet been fixed, I thought it best to tell you. Thank you, Ben Davis http://bdavis.netfirms.com/