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

Internet Message Format | 1992-12-24 | 3.1 KB

Xref: sparky comp.sys.sgi:18328 comp.sys.sgi.bugs:44 comp.unix.ultrix:9075
Newsgroups: comp.sys.sgi,comp.sys.sgi.bugs,comp.unix.ultrix
Path: sparky!uunet!mcsun!sun4nl!fwi.uva.nl!casper
From: [e-mail] (Casper H.S. Dik)
Subject: Re: tempnam(3S) bug, possibly on all MIPS
Message-ID: <[e-mail]>
Sender: [e-mail]
Nntp-Posting-Host: adam.fwi.uva.nl
Organization: FWI, University of Amsterdam
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 24 Dec 1992 09:03:22 GMT
Lines: 65

[e-mail] (Tony Apodaca) writes:

>In an article, [e-mail] (T.C. Zhao) writes:
>>| It appears that tempnam(3S) is broken on three MIPS machines I have
>>| access to:   IRIX 3.3, Ultrix 4.1, UMIPS 4.52:

>In an article, [e-mail] (Dave Olson) writes:
>>Since tempnam() needs to make sure the file it is existing doesn't
>>exist, it isn't surprising that errno is set (but you shouldn't
>>count on it either way!).

>In an article, [e-mail] (Rick Murphy) writes:
>>Looking at errno after calling a library routine that hasn't failed isn't
>>a useful thing to do. The call succeeded - you've got no reason to go looking
>>at errno.

>    This is not really the point.  The point is that a smart programmer
>checks errno after every system call.

You have a totally different conception of smart than most of us.
You may only inspect errno after a FAILED system call. If you examine
errno after a library call or after a succesfull system call,
it can have any value. Some manuals explicitly state that a successfull
system call will not touch errno, others even leave room for that.

It is generally accepted, though that errno is not touched by successful
system calls for one simpel reason: some system calls can return any
value, and must be called in the following manner:
        errno = 0; val = syscal(); if (errno) .....

>It makes you go into defensive programming mode, setting errno to 0 before
>every system call because you don't know if there are any *other* library
>routines which break the rules and have unexpected unfriendly side effects
>like this.

>    Okay, maybe I'm exaggerating to make a point, but I don't think
>it's fair to insinuate that Mr. Zhao is wrong.  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?

No, the manual states that errno isn't touched on `successfull SYSTEM calls'.
It says nothing about other successfull calls. It is in
fact quite common for a library call to set errno to some unexpected value.

E.g., this piece of code has a bug:

    if (write (....) == -1) {
        fprintf(stderr,"some message")'
        perror("write");
        exit(1);
    }

(Hint: why do a number of programs always print ``Not a typewriter'' or
 ``Inappropriate ioctl for device'' when they detect an error code?)

Or do you want all library programs to bracket their code with:

    savederrno = errno;
    ......
    errno = savederrno; /* on successfull returns only */

I think not.

Casper