Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!princeton!udel!gatech!hao!ames!necntc!ima!haddock!karl
From: karl@haddock.UUCP
Newsgroups: comp.lang.c
Subject: Re: Question on ANSI C compatibility
Message-ID: <1761@haddock.ISC.COM>
Date: Thu, 19-Nov-87 12:37:30 EST
Article-I.D.: haddock.1761
Posted: Thu Nov 19 12:37:30 1987
Date-Received: Sat, 21-Nov-87 15:59:39 EST
References: <10224@brl-adm.ARPA> <9272@mimsy.UUCP> <1804@geac.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Boston
Lines: 33

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? if necessary from the presence of "extern int
>errno; return ERR" in a lintlibrary entry?

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 is inappropriate -- the trouble is that it would cause lint to be silent
in the much more common case when the user checks neither the return value nor
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();

However, the following incorrect code does not and cannot generate a warning
for the unchecked error return:
  FILE *fp = fopen(fname, "r");
  int c = fgetc(fp);

My conclusion?  Error signaling in C could use a complete overhaul.  I've got
several ideas% on how it could be improved.  It's unfortunate that the
existing setup is carved in stone.  (Will there ever be a "D" language%%?)

Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint

%Some of you may remember that I was going to post them last February.  Sorry,
I never finished writing up the argument.  It's been suggested that I convert
it into a USENIX talk.  We'll see.

%%Please don't followup just to say it should be named "P".