🚀 go-pugleaf

In article <4906@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes:
> In article <4900@mimsy.UUCP> mangoe@mimsy.UUCP (Charley Wingate) writes:
>> Barry Shein writes:
>>> Perhaps [always running lint] should be an extension or option to
>>> CC commands ...
>> You still haven't explained why lint as a processor should be
>> logically and functionally distinct from cc as a processor.
> How about the *time* it takes to run lint?
> [also]
> [S]eparating them gives YOU the *option* of deciding whether to
> expend computer time checking for tricky or otherwise dubious code.

Not to mention the fact that lint often yells about things it
shouldn't, and it is even occaisonally outright wrong.

For example, I seem to recall that there is some routine (read()?)
which has an argument that lint and lint -p disagree over the correct
type for.  Not good.

For another example, I refuse to uglify my code with (void) casts just
to make lint shut up about strcpy(), close(), fprintf(stderr,...), etc,
returning values that I don't use.  This is one thing lint *needs*: a
way to say "this routine returns a value, but it's OK to ignore it".

There also should be a way to shut off lint complaints about
nonportable code in just a small region that you know is
machine-specific (eg, stuff inside #ifdef machine-type).

					der Mouse

USA: {ihnp4,decvax,akgua,utzoo,etc}!utcsri!mcgill-vision!mouse
     think!mosart!mcgill-vision!mouse
Europe: mcvax!decvax!utcsri!mcgill-vision!mouse
ARPAnet: think!mosart!mcgill-vision!mouse@harvard.harvard.edu