NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/comp/sys/sgi/18335

Text File | 1992-12-24 | 1.8 KB | 42 lines

Newsgroups: comp.sys.sgi
Path: sparky!uunet!psinntp!pixar!news
From: [e-mail] (Bruce Perens)
Subject: tempnam() and errno non-bug
Message-ID: <[e-mail]>
Sender: [e-mail] (Usenet Newsmaster)
Nntp-Posting-Host: kvetch.pixar.com
Organization: Pixar -- Point Richmond, California
References: <[e-mail]>
Date: Thu, 24 Dec 1992 20:12:59 GMT
Lines: 29

In article <[e-mail]> [e-mail] (Tony Apodaca)
writes:
[Regarding tempnam() setting errno even though tempnam() has not failed.]
> It *is* a bug, in the
> following sense: the man pages explicitly state that errno is set if a
> system call gets an error, but is untouched otherwise.  I think library
> utility functions fall into the "otherwise" category, don't you?

I don't agree that it's a bug.

Library functions are allowed to make system calls, thus library functions
may set errno when the system calls fail. This is
the case with tempnam() - it uses a system call to check if the name
it has created exists in /tmp. If the system call succeeds, the name
exists and tmpnam() picks another name and uses the system call to
check it. Thus, the system call must fail before tempnam() returns.

The cautious programmer always checks the return value of a system call
for a failure indication, and never looks at errno except immediately
after a system call has returned indicating an error. The value of errno
is un-defined at any other time if you are using library functions, since
those library functions may make system calls as they please, and those
system calls may fail.

Most Unix programmers stumble over this at some point.
It's certainly non-intuitive. A more modern design would use something
other than a global variable for errors - perhaps the C++ "exception"
facility will help here.
                    Bruce Perens