Can lint help an ANSI-C programmer?

[diamond@tkovoa]

In article <6328.265D8157 at puddle.fidonet.org> cspw.quagga at p0.f4.n494.z5.fidonet.org (cspw quagga) writes:

>I'm after some advice on lint:  I don't use it, and want to know whether
>I should.

You should.  The question, as you point out below, is whether you CAN.

>1. Is it ANSI C compatible?

Either no or mostly no.  There might be one that I haven't heard of.

>(Or are there many dialects of lint?

Yes.  Maybe half as many as there are C compilers.  (It should be equally
many rather than half of many, but some vendors are irresponsible.)

>   Would a Xenix lint be the same as most others?)

How many others constitute "most"?  If you mean others that are all
the same among these others' selves, there is no "most".

>   Is lint likely to discover anything new or give useful advice after this
>   gauntlet?

Yes.  It is also likely to give useless advice and false error messages
(if you use things like prototypes).  If you choose to program in a
subset of ANSI C, one that is a subset of the intersection of ANSI C
and many old C's, then the amount of useless advice can be minimized,
and you can pay attention to the useful advice.

>Are there still things that lint can discover (by looking at all
>   modules simultaneously) that a C compiler cannot discover when modules are
>   compiled independantly?

Yes, dozens.

>3. Was the intention that ANSI C with prototypes/casts etc.  would remove the
>   need for external checkers like lint?

If prototypes and header files are used properly, then they can duplicate
a little bit of lint's work.  The answer to this half-question might be
5% yes and 95% no.  How do casts add any error checking?  In fact, they
usually defeat error checking.  And what did ANSI do to casts? The answer
to this half-question might be -50% yes and +150% no.

>Can we expect to see the demise of lint in the next few years?

Well, error checking is pretty widely unpopular, so the answer might be yes.
But neither expectation (demise vs. revival) affects the work that most
of us do, so it might not be necessary to try to predict this.

-- 
Norman Diamond, Nihon DEC     diamond at tkou02.enet.dec.com
Proposed group comp.networks.load-reduction:  send your "yes" vote to /dev/null.