[comp.software-eng] What does lint do?

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.

jls@netcom.COM (Jim Showalter) (05/30/91)

What does lint do? Lint does all the stuff C compilers OUGHT to do, but
don't. Using this clever trickery, one hears of how "compact" and "efficient"
C compilers are (usually in comparison to something like an Ada compiler)...
but this is a completely bogus argument. I could write a really compact
and efficient Ada compiler too, if I didn't have to do any type checking,
bounds analysis, or much of anything else I've come to expect from a
software engineering language (actually, I COULDN'T, since Ada compilers
are validated, but you get the idea).

I remember back in another lifetime when I used to work for a UNIX shop
the justifications made for the C compiler not doing much checking: "We
can always run it through 'lint'.". Of course, they never DID run it
through lint, because they found that when they did it flagged all sorts
of errors, and this presented a major inconvenience to them. Much better
for the CUSTOMER to act in the role of lint, finding most errors in the
field. This made no sense at all to me at the time (and still doesn't)
but hey, what do I know?--I'm not a hacker.
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

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.

cml@cs.umd.edu (Christopher Lott) (05/30/91)

In article <1991May29.173713.7058@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>I remember back in another lifetime when I used to work for a UNIX shop
>the justifications made for the C compiler not doing much checking: "We
>can always run it through 'lint'.". Of course, they never DID run it
>through lint, because they found that when they did it flagged all sorts
>of errors, and this presented a major inconvenience to them. Much better
>for the CUSTOMER to act in the role of lint, finding most errors in the
>field. This made no sense at all to me at the time (and still doesn't)
>but hey, what do I know?--I'm not a hacker.


I do wish to throw in my $.02 to say that I convinced an old boss of mine
to purchase Gimpel Lint for use on the PC - we were using MS C at the time -
and once he saw early results, he happily took the time to run all of his code
as well as all of the code in the project through that beast.  Founds lots of
stuff, wish I could remember juicy examples, but can't.  Anyhow, they soon
swore by it, at least most of them did.  But naturally there were some who
didn't see the use.  I had unpleasant experiences with one, who when shown
the deficiencies in his code, still refused to make changes, etc, etc.

So there are folks who use lint and swear by it, especially when gcc is not or
can not be available.  But there are also still plenty of cowboys out there,
folks who run a software business like sh*t. 

And Mr Showalter also seems to enjoy baiting those of us who like C, but I
will not rise to the bait.  It's too hot here to get all worked up.

chris...

p.s. note lack of signature soliciting business.  it's a grey area, putting
such dreck in your sig, but I for one don't like it.
-- 
Christopher Lott \/ Dept of Comp Sci, Univ of Maryland, College Park, MD 20742
  cml@cs.umd.edu /\ 4122 AV Williams Bldg  301 405-2721 <standard disclaimers>

jls@netcom.COM (Jim Showalter) (05/30/91)

>And Mr Showalter also seems to enjoy baiting those of us who like C, but I
>will not rise to the bait.  It's too hot here to get all worked up.

No bait intended--a question was asked about lint, I gave an answer based
on my own experiences working with C people. Granted some C people are
better than others--to the good ones the necessity of running lint on all
code before inflicting it on the end user seems obvious (obvious enough
that some of them even ask heretical questions like "Why isn't it built
into the compiler in the first place?"...). To others, lint is something
evil and nasty and not to be trusted because it points an accusatory
finger at poor quality, hacked-together code; not surprisingly,
those who react this way tend to be the ones who produce such code.

>p.s. note lack of signature soliciting business.  it's a grey area, putting
>such dreck in your sig, but I for one don't like it.

Yeah, well--you've got a steady job. How about cutting those of us who work
freelance a little slack?
-- 
**************** JIM SHOWALTER, jls@netcom.com, (408) 243-0630 ****************
*Proven solutions to software problems. Consulting and training on all aspects*
*of software development. Management/process/methodology. Architecture/design/*
*reuse. Quality/productivity. Risk reduction. EFFECTIVE OO usage. Ada/C++.    *

rlk@telesoft.com (Bob Kitzberger @sation) (05/31/91)

In <35026@mimsy.umd.edu> cml@cs.umd.edu (Christopher Lott) writes:

>I do wish to throw in my $.02 to say that I convinced an old boss of mine
>to purchase Gimpel Lint for use on the PC - we were using MS C at the time -
>and once he saw early results, he happily took the time to run all of his code
>as well as all of the code in the project through that beast.  Founds lots of
>stuff, wish I could remember juicy examples, but can't.  Anyhow, they soon
>swore by it, at least most of them did.  But naturally there were some who
>didn't see the use.  I had unpleasant experiences with one, who when shown
>the deficiencies in his code, still refused to make changes, etc, etc.

I'm glad that you got your company to use it... it's a step up.  Do folks 
use it EVERY TIME they compile?  Or is it 'once every ten bug fixes' or
'once before we ship it'?  I'm not insinuating that this is the way your
shop does it, merely pointing out that I've yet to see someone that uses lint
(anywhere near) each time they make a source change.  

I've spent too much time tracking down bugs that lint (if I had it) or
a better language than C would have caught earlier on in the development 
process.  On a personal level, debugging obscure problems introduced due 
to the lack of compile-time checks grew old after a year or two.  On a 
professional level, it's insane and negligent to check for bugs later 
in the development cycle than it is, within reason, possible to detect them.

Trying to catch bugs at design time rather than compile time,
at compile time rather than unit test,
at unit test rather than at integration,
at integration rather than customer time, I remain,

	.Bob.
-- 
Bob Kitzberger               Internet : rlk@telesoft.com
TeleSoft                     uucp     : ...!ucsd.ucsd.edu!telesoft!rlk
5959 Cornerstone Court West, San Diego, CA  92121-9891  (619) 457-2700 x163
------------------------------------------------------------------------------
"Wretches, utter wretches, keep your hands from beans!"	-- Empedocles

alesha@auto-trol.com (Alec Sharp) (05/31/91)

>
>I'm glad that you got your company to use it... it's a step up.  Do folks 
>use it EVERY TIME they compile?  Or is it 'once every ten bug fixes' or
>'once before we ship it'?  I'm not insinuating that this is the way your
>shop does it, merely pointing out that I've yet to see someone that uses lint
>(anywhere near) each time they make a source change.  
>

I'm a lint fanatic and my practices for several years have been: 

1.  Compile code 

2. Lint code using Gimpel's Flexelint (a wonderful product, vastly
better than the lint that comes with UNIX) so that it's completely
error and warning free.  You can turn off certain errors and I have a
very strict, small set of things that are ignored.  

3. Link code and test.  

4. Debug and fix.  If there are errors, compile and lint again.

Lint doesn't take long on a single program, especially relative to the
time it takes to link and test.  Flexelint allows you to lint a single
program, without complaining about the non-use of globals etc.  ANSI C
gives you prototype functions (which Flexelint checks), so you can
check a single program relative to how it fits in with the rest of the
world.

Using lint from the start, and using it religiously, has virtually 
eliminated implementation errors (as opposed to functionality errors).

Alec Sharp...


-- 
------Any resemblance to the views of Auto-trol is purely coincidental-----
Don't Reply - Send mail: alesha%auto-trol@sunpeaks.central.sun.com
Alec Sharp           Auto-trol Technology Corporation
(303) 252-2229       12500 North Washington Street, Denver, CO 80241-2404

jja@wsl.ie (John Allen on wsl) (06/07/91)

In article <1991May29.173713.7058@netcom.COM> jls@netcom.COM (Jim Showalter) writes:
>What does lint do? Lint does all the stuff C compilers OUGHT to do, but
>don't. Using this clever trickery, one hears of how "compact" and "efficient"
>C compilers are (usually in comparison to something like an Ada compiler)...
>but this is a completely bogus argument. I could write a really compact

I have to completely agree with you for a change. Normally I only half agree
with you. link sucks. I love ANSI C & C++ because they bring back all that
type-checking I used to have in PASCAL. 

I think the proponents of 'lint' ought to be shot, it's like sayin a C compiler
should accept ADA/C++/PASCAL/BASIC etc... as input and just produce some sort 
of object file that will core dump.

-------------------------------------------------------------------------------
		|\/\/\/|
		|      |
		| (-)(o)
		|     _)
		| ,___|    
		|   /   
	   /____\   And the BART raised up his hands and said unto the masses.

People that don't know want to know from the people that do know and if the 
poeple that do know don't tell the people that don't know then the people
that don't know still won't know.
   "Don't quote me on any issue whatsoever, unless you feel oblidged to."

yogi@cs.ubc.ca (Joseph Gil) (06/09/91)

Turbo C 2.0 and up with all the warnings turned on, beats the 
hell out of lint!

If you are looking for static tests, this is the place to look!