Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!frog!john
From: john@frog.UUCP (John Woods, Software)
Newsgroups: comp.lang.c
Subject: Re: Question on ANSI C compatibility
Message-ID: <1946@frog.UUCP>
Date: Fri, 20-Nov-87 15:28:00 EST
Article-I.D.: frog.1946
Posted: Fri Nov 20 15:28:00 1987
Date-Received: Mon, 23-Nov-87 02:55:54 EST
References: <10224@brl-adm.ARPA> <9272@mimsy.UUCP> <1804@geac.UUCP> <1761@haddock.ISC.COM>
Organization: Superfrog Heaven [ CRDS, Framingham MA ]
Lines: 28

In article <1761@haddock.ISC.COM>, karl@haddock.ISC.COM (Karl Heuer) writes:
> In article <1804@geac.UUCP> daveb@geac.UUCP (Dave Collier-Brown) writes:
>>Can we come up with a criteria for "dullness" which lint can infer by itself
> You seem to believe that the return value of, say, "unlink" should be
> considered "dull" because the user can ignore its value and check errno.
> ...This code is correct, but unavoidably generates a lint warning (though it
> can be silenced with a (void) cast):
>   errno = 0;
>   unlink(fname);
>   if (errno != 0) abort();
> 
The preceeding code is absolutely, unequivocably, wrong.  unlink() is not
in the ANSI C spec at all.  P1003.1 and SVID are the relevant specifications,
and they both state that "The value of errno should be checked only after an
error has been indicated" (SVID) "The value of errno should be examined only
when it is indicated to be valid by a function's return value" (P1003.1
Draft 12).  _errno_ is an ERROR indicator, not a success indicator, in these
standards.


--
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, ...!mit-eddie!jfw, jfw@eddie.mit.edu

"Cutting the space budget really restores my faith in humanity.  It
eliminates dreams, goals, and ideals and lets us get straight to the
business of hate, debauchery, and self-annihilation."
		-- Johnny Hart