From:	"Ben Davis" <ben AT vjpoole DOT freeserve DOT co DOT uk>
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/

- Raw text -