Subject: Re: ARGSUSED and friends
To: None <firstname.lastname@example.org, email@example.com>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 01/30/2000 03:19:00
[Seems to me this belongs on tech-toolchain. This will be my last
message to tech-kern on this thread.]
>> That's why I use gcc with various warning options instead [of lint]
> Personally I believe a *compiler* has no business at all warning me
> about some potentially non-portable construct or some code that's not
> going to do what I mean it to do so long as it is syntactically
> correct. A compiler should compile the code presented to it as
> quickly and efficiently as possible. If you want to do code
> analysis, strong type checking, portability checking, etc., then you
> should do that in a separate program.
There is a tension here between two values:
(1) One job per program, one program per job
(2) Don't do the same thing two different places
As you say, (1) certainly argues for making the compiler fast and lean,
with minimal checking. (Indeed, carried to an extreme, it would not
even do syntax checking, with the results for syntax errors being
"whatever the implementation happens to give", the philosophy being
that you should check the code before you compile it.)
But (2) is also forceful. Putting the checking and the compiler in the
same program means that neither has to duplicate work the other already
does, by which I mean everything from parsing to data flow analysis.
It also guarantees that you never find version skew between the checker
and the compiler.
There's yet another argument in favor of doing checking and compiling
in a single program: that way seems to have less trouble finding people
to work on it. Compare the amount of development available for new gcc
work versus the amount of effort available for souping up lint and/or
building a "lean and mean" compiler.
> Steve Johnson  described all kinds of interesting things that a
> lint could do that no compiler alone could so easily accomplish,
> things that were only hinted to in his original paper oh so many
> years ago. Unfortunately many of those ideas remain unimplemented to
> this day.
Who is going to bell the cat?
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B