lint fails to be my friend

[Doug Gwyn]

In article <1991Apr04.212837.13505 at ima.isc.com> suitti at ima.isc.com (Stephen Uitti) writes:
>With ANSI C, exit() is essentially part of the language, so maybe
>lint could be better.

And indeed some versions of "lint" ARE better.

>Traditional 'lint' uses the 'pcc' parser.  Great.  If 'pcc'
>didn't care, then 'lint' can't derive the information.

That's not entirely accurate, even for pre-ANSI C "lint".
There are several utilities within the "software generation system"
that share source code, but each of them tends to have its own
special pieces of support within the shared code.

(I think it was "ctrace" that I decided to also bring into the fold
rather than giving it its own slightly edited version of the SGS
sources as it was shipped with SVR2.)

>I've worked with compilers that tell you what they expected.
>Once you get used to it, it is extraordinarily helpful.  Our
>friend 'lint', says "Syntax error" too.

Yes, such diagnostics as you mentioned are nice.  The generic
"syntax error" style of message is often due to the use of a
parser generator (such as "yacc") with insufficient care given
to its error-reporting and -recovery capabilities.  At least
the SVR2 "lint" and PCC recover from syntax errors considerably
better than some other implementations I've seen, wherein the
least little typo produces literally hundreds of spurious
subsequent diagnostics.  (Might as well make the first diagnostic
fatal in such a case!)

>Lint belongs in the compiler, anyway.

No, I disagree.  SYNTAX CHECKING is perhaps best done by a genuine
compiler, but that is NOT the only task that "lint" performs.  In
particular, "lint" is used to check for nonportabilities, possible
unintended but valid C usage, intermodule linkage compatibility,
and so forth, none of which would I WANT a C compiler to do.  The
compiler should correctly and SILENTLY translate a correct program
to efficient code, not try to second-guess the programmer.