Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!helios!archone!byron
From: byron@archone.tamu.edu (Byron Rakitzis)
Newsgroups: comp.lang.c
Subject: Re: lint (was: Funny mistake)
Message-ID: <13619@helios.TAMU.EDU>
Date: 22 Mar 91 07:08:43 GMT
References: <13584@helios.TAMU.EDU> <1991Mar22.055335.23091@athena.mit.edu>
Sender: usenet@helios.TAMU.EDU
Organization: College of Architecture, Texas A&M University.
Lines: 50

In article <1991Mar22.055335.23091@athena.mit.edu> scs@adam.mit.edu writes:
>In article <13584@helios.TAMU.EDU> byron@archone.tamu.edu (Byron Rakitzis) writes:
>>How many people remember to run lint on their code? How many do
>>it at the last minute?
>
>It's unfortunately true that "classic" versions of lint tend to
>require a bit of bondage and discipline to keep them quiet.
>Nobody said programming was easy.  I wouldn't particularly mind it
>if compilers tended to emit a few more "handholding" messages, as
>long as it didn't make them bigger and buggier, but I certainly
>don't mind running lint to catch mistakes that the compilers
>shouldn't, can't, don't, or won't.
>

I don't think that a compiler has to be big in order to perform the
tasks outlined. You are just prejudiced by the current state of 
commercial compilers and gcc. The compiler I am working on will
operate in two stages, a cpp/parser/ir-generator and a code-generator/
linker, and I am aiming for a factor of 3-5x compile-time speedup over
gcc, plus a 3-5x reduction in compiler source code size. Impossible?
Hardly. Compilers are in a sad state these days. Really sad.

>I don't understand why it takes anything to "remember" to run
>lint on your code.  (If you can't run it, because your
>lackadaisical vendor sold you half a compiler, that's another
>story.)  How do you remember to look for bugs at all?

I don't think that good coding style should depend wholly on
receiving enlightenment from Henry Spencer's 10 commandments
("thou shalt run lint.."). I think a newcomer to Unix or to C
should be able to depend on the compiler to generate the necessary
diagnostics to encourage some semblance of a good coding style.
I admit that this compiler will be a hand-holder, but I also think
that it can be done with good taste. And Real-Programmers(tm) can
always turn the diagnostics off. But I think it's crucial to
present these diagnostics by default, since otherwise they are
ignored by the user.

I guess what I'm trying to say is, why should someone have to run
lint on their code to figure out what's wrong with it when it's
perfectly reasonable for the compiler to provide a similar service
by default? Are there people out there who deliberately WANT to
write bad code? I'm not talking about the 5-minute foo.c hack, I'm
talking about software development.

A good compiler that does C preprocessing in the same pass as
lexical analysis should be no slower than lint for this job.
Also, if you let compilation proceed to the point where the
compiler can do some dataflow analysis, then you can get diagnostics
regarding use of unassigned variables, and so on.