home *** CD-ROM | disk | FTP | other *** search
- Xref: sparky comp.sys.sgi:18270 comp.sys.sgi.bugs:33 comp.unix.ultrix:9038
- Newsgroups: comp.sys.sgi,comp.sys.sgi.bugs,comp.unix.ultrix
- Path: sparky!uunet!zaphod.mps.ohio-state.edu!sdd.hp.com!usc!sol.ctr.columbia.edu!eff!world!cmr
- From: cmr@world.std.com (Charles M Richmond)
- Subject: Re: tmpnam/tempnam
- Message-ID: <Bzo3pt.3tA@world.std.com>
- Organization: Integrated International Systems Corp. One Longfellow Place, Suite 3309, Boston, Ma.
- References: <BzKIrq.GqI@world.std.com> <1992Dec22.143124.7110@julian.uwo.ca>
- Date: Tue, 22 Dec 1992 15:44:17 GMT
- Lines: 26
-
-
- kinch@valve.heart.rri.uwo.ca
-
- >You can argue style if you like but the point is that errno is not tested
- >until it is known that an error has occured.
- >Just because ENOENT was probably generated internally in tmpnam() doesn't
- >mean that it will be that after the call. It would be perfectly reasonable
- >and legal behaviour to clear errno (or set it to a completely bogus value)
- >if the call succeeds.
- >Just trying to keep the misinformation down to a minimum.
-
- If you really want to run a tight loop on generating a unique filename
- then you probably do not want to do a fileopen for each iteration. You
- can depend on the internal check in all but the homebrew pseudo UNIXs.
- I suppose that you could look at the source for these to verify their
- functionality. If I can , I'll try to find some doc for this. I had a
- momentary lapse of memory, but I do remember this from the "good old
- days". Of course if this is a feature that is no longer "officially"
- supported then one would have to discontinue using it. )-:
-
- Charlie
- --
- *****************************************************************************
- * Charles Richmond Integrated International Systems Corporation *
- * cmr@world.std.com (Temporary) cmr@koneko.shr.dec.com *
- * Specializing in UNIX, X, Image Processing, and Communications. *
-