cl@lgc.com (Cameron Laird) (05/29/91)
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
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.mcdaniel@adi.com (Tim McDaniel) (05/30/91)
In article <91-05-108@comp.compilers> cl@lgc.com (Cameron Laird) writes:
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.
Gimpel Software's FlexeLint is fully ANSI-compatable. It can also handle
most pre-ANSI constructs and semantics. It is an excellent product,
primarily because each message can be individually turned on or off, within
parts of a source file or for particular symbols or files. (Disclaimer: I'm
just a satisfied customer; I have no financial interest in G. S.)
Gimpel Software
3207 Hogarth lane
Collegeville, PA 19426
1 215 584 4261
It can be run on SUNs, VAXen, PCs, et cetera.
--
Tim McDaniel Applied Dynamics Int'l.; Ann Arbor, Michigan, USA
Internet: mcdaniel@adi.com UUCP: {uunet,sharkey}!amara!mcdaniel
--
Send compilers articles to compilers@iecc.cambridge.ma.us or
{ima | spdcc | world}!iecc!compilers. Meta-mail to compilers-request.