Xref: utzoo comp.lang.misc:2459 comp.lang.c:15266 comp.lang.c++:2358
Path: utzoo!utgpu!attcan!uunet!lll-winken!lll-lcc!ames!pasteur!ucbvax!ernie.Berkeley.EDU!jas
From: jas@ernie.Berkeley.EDU (Jim Shankland)
Newsgroups: comp.lang.misc,comp.lang.c,comp.lang.c++
Subject: Re: Yet Another Lint Foul-up
Keywords: Idle curiosity.
Message-ID: <27381@ucbvax.BERKELEY.EDU>
Date: 6 Jan 89 17:52:52 GMT
References: <1298@tank.uchicago.edu>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jas@ernie.Berkeley.EDU.UUCP (Jim Shankland)
Organization: University of California, Berkeley
Lines: 36

In article <1298@tank.uchicago.edu> vevea@paideia.UUCP (Jack L. Vevea) asks
(paraphrased), why people make a fuss about lint messages that they
know to be inconsequential -- is it that a higher authority requires
that their code be lint-free, or are they just being obsessive "slaves
to lint?"

Sometimes, a higher authority does require lint-free code.  This is not
a bad thing, even if you do have to do some pretty strange things
(e.g., using "#ifdef lint") to make it happen.  Even when there is no
such higher authority, it's a good idea to arrange for code to be
completely lint-free.  While I *know* that "possible pointer alignment
problem" on return from malloc() is inconsequential, other, even
more highly paid software engineers :-) "know" that all kinds of other
lint messages are inconsequential, because the code works fine on their
VAX.  This is a sad fact; very sad, but very much a fact.

Second, if my code generates n inconsequential lint messages, then every
time I re-lint the code, I have to pick out the "real" lint, if any,
from the n inconsequential messages.  This is burdensome and error-prone.
Better to habitually use a few contrivances that eliminate the harmless
lint messages.

(Of course, the above-mentioned software engineers may then put all sorts
of unsafe weirdness into their code "to shut lint up".  Ultimately,
this is a major problem with C:  it's too easy to write non-portable code,
and too hard to specify the rules for writing portable code.  No, I'm
not proposing a solution, and I'm certainly not saying we should all
be programming in Pascal -- just pointing out a *very* costly problem
with the language.  If you doubt me, consider this small example:
what percentage of C programmers do you think know what the correct
definition of NULL is, and when NULL needs to be preceded by a type cast,
despite regular clarifications of the question in comp.lang.c?  No
fair counting those who "know" an answer that is wrong!)

Jim Shankland
jas@ernie.berkeley.edu