Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: lint (was: Funny mistake)
Message-ID: <5036@goanna.cs.rmit.oz.au>
Date: 22 Mar 91 10:23:07 GMT
References: <13584@helios.TAMU.EDU> <1991Mar22.055335.23091@athena.mit.edu> <13619@helios.TAMU.EDU>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 16

In article <13619@helios.TAMU.EDU>, byron@archone.tamu.edu (Byron Rakitzis) writes:
> 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.

More power to you!  While you're at it, how about an _increase_ in
comment density?

But will your hand-holding compiler check that a *group* of files are
consistent?  That's what I really depend on lint for.
-- 
Seen from an MVS perspective, UNIX and MS-DOS are hard to tell apart.