Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!seismo!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.lang.c
Subject: Re:  questions from using lint
Message-ID: <531@brl-smoke.ARPA>
Date: Mon, 5-May-86 00:46:38 EDT
Article-I.D.: brl-smok.531
Posted: Mon May  5 00:46:38 1986
Date-Received: Thu, 8-May-86 04:37:38 EDT
References: <531@bu-cs.UUCP>
Reply-To: gwyn@brl.ARPA
Organization: Ballistic Research Lab (BRL)
Lines: 84

Barry, the point is, if you have a decent version of "lint",
then ANYthing it warns you about really could be an error.
It is not always obvious to the non-expert what the problem
could be, but I haven't seen more than a few actual errors
made by our SVR2+ "lint".  Therefore, if you really do want
your code to port without hassle, you should pay attention
to what "lint" tells you about your code.  Furthermore, for
this approach to be maximally helpful, you want to reduce
the not-really-a-problem messages so that real problems do
not get buried among the non-problems.  The main category
of "lint" messages that do not indicate bugs or possible
portability problems is the detection of unused variables,
functions, parameters, and function values.  Most of these
are probable errors in the code.  The one that seems to
bother people most is the flagging of unused function values.
The naive idea that one then sticks "(void)" in front of all
such function invocations "just to shut lint up" indicates a
misunderstanding of what lint is all about.  If one's own
functions do not return values, they should be declared of
type void.  If a function's value is sometimes important
and sometimes not (good examples of this are fairly rare),
then one should explicitly indicate discarding of the value,
which is the proper use of (void).  This shows whoever reads
the code that the matter has been thought about and indeed
the value is not needed in that invocation (it also forces
you to think about the matter when you write the code).  The
final instance involves standard library functions; I claim
that robust code really must check the majority of function
returns (strcpy() is a notorious exception, since it doesn't
tell one anything useful).  I just finished writing an MDQS
despooling slave both with and without using stdio for device
output; in order to detect problems with the output device
and perform appropriate error recovery, it was essential to
test the return values from putchar(), fflush(), and other
such functions that most programmers do not test.  The fact
that "lint" encourages one to program responsibly is good!

If you follow my recommendation and try to make your code
lint-free in the first place, then ANY noise from "lint"
will necessarily call your attention to a bug.  This is
extremely helpful, but it only works well if the expectation
is that there will be no "lint" output for correct code.

Now, if you want to just "hack around", then "lint" is not
for you; but if you're producing production-quality C code,
there is no excuse for delivering unduly linty code.

In answer to your question, yes, I think one has a right to
expect C source code deliverables (pretty rare these days)
to be lint-free.  Every time we get code that hasn't been
done that carefully, it doesn't work right and a lot of time
has to be spent fixing it.  This should be the vendor's
responsibility, not the customer's; but a vendor that ships
code like that probably won't be able to fix it properly
either.

P.S.  Unless your malloc() has type (void *), "lint"
warnings about incompatible pointer conversion will be
unavoidable, since "lint" doesn't realize that malloc()
arranges its (char *) return value to be maximally
aligned.  This is one of the few "lint" warnings that
correct code should produce, and it is easy to spot.
But beware the yo-yo who fails to declare the malloc()
function, invokes it (as a default int-valued function),
and casts the result to (char *); that's incorrect usage.

P.P.S.  Don't look to the UNIX sources for good examples
of lint-free code; some of them are good, but most are
horrible.

P.P.P.S.  I agree with the fellow who identified the
major problem as poor programming management.  C code
quality is only a small part of overall software quality.
All too often, one sees programmers writing code before
a proper job of analysis and design has been done.  I
also believe that is partly because semi-running code
makes it appear as though progress has been made,
while a complete design doesn't convey the same impression.
The only solution is to educate the management involved.
There are many good books (mostly from Yourdon, Inc.)
that can be used to help with this; my experience has
been that such educational efforts are only partially
successful, but that partially correct organization of
the software development process is better than none.