What does lint do?

Over a month ago, I generated an inquiry about the theory of lint, as a
concrete instance of static analysis. I still haven't recognized the One
True Answer in anything that has crossed my screen since then, but I do think
other readers deserve to share the riches that have come my way. I'm broad-
casting this to four newsgroups because I've seen related issues in each of
the newsgroups, recently.


Thanks go to Guy Harris, bremner@cs.sfu.ca, Dana Hoggatt, David Keppel, James
Davies, Andy Glew, Eric Hancrow, Ian Dar- win, Tim McDaniel, and Richard
Stallman. A melange of direct quotations and my summaries follows:
--------------------------------------------------------------


ANSI has no standard for lint. No one else does, either (not even POSIX?
We're not sure). There are very few lints (maybe only two: the original, and
Gimpel), and they haven't kept up with such language features as function
prototypes. There are some commercial portability suites (Abraxas, ...) I'm
investigating ...


ANSI standards do NOT specify the action of the C compiler when it encounters
erroneous or questionable input.


A number of folks (including me, on alternate days) see lint as a dead-end;
GNU-progenitor Richard Stallman even labels it "obnoxious". Ian Darwin, on
the other hand, found it rewarding enough to warrant publication of a book,
*Checking C Programs with Lint* (O'Reilly, 1988, and not due to be updated
until later in 1991).


"LALR(1) parsers (YACC, BISON,...) have pitiful error detection and recovery.
As far as I can tell, everyone has given up on it."


"A top down recursive descent parser with more than 1 token of look-ahead
should be capable of generating any level of detail you wish to implement in
the way of syntax errors. They are just tedious and time-consuming to do by
hand."


For info on static analysis in general ( what lint does ) you might pick up
any denotational semantics book. _Introduction to the theoriy of programming
languages_ , Meyer, Prentice-Hall, 1990, is not bad, although it has a few
typos. For info on actual applications:
RXVP-80 (Smalltalk ), in _Software Verification
and Validation: Realistic project approaches_,
Micheal S. Deutch, Prentice-Hall, 1982


The standard introduction to compiler design (in the US, anyway) seems to be
what's usually called `The Dragon Book' (because there's a picture of a
dragon on the cover): Aho, Alfred V. Compilers -- principles, techniques,
and tools. Joint authors: Sethi, Ravi, and Ullman, Jeffrey D. 1987, Addison
Wesley.


"Lint, a C Program Checker", Computer Science Technical Report 65, Bell Labs,
Murray Hill, NJ. updated version TM 78-1273-8.


People generally rate gcc higher than the combination of cc-and- lint.


"The only approachs I know of for dealing with semantic errors, is to treat
them as syntax errors, either by letting the core parser fail in a 'I don't
know' state, or by adding specific grammar rules for each semantic condition
you want to detect."
--


Cameron Laird +1 713-579-4613
cl@lgc.com (cl%lgc.com@uunet.uu.net) +1 713-996-8546
--

Return to the comp.compilers page.
Search the comp.compilers archives again.