lint as a part of cc

[karl at haddock.UUCP]

[Followups to comp.lang.c, unless other languages are discussed.]
In article <593 at mcgill-vision.UUCP> mcgill-vision!mouse (der Mouse) writes:
>In article <4906 at mimsy.UUCP>, chris at mimsy.UUCP (Chris Torek) writes:
[Concerning whether lint should be an enforced part of cc]
>>Separating 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.

More precisely, lint feels free to complain about things that *might* be
wrong, on the grounds that it was explicitly invoked by the user to look for
such things.  If it were built into cc (and some parts of it should be, and
have been; e.g. "pointer == integer"), it would have to give the user the
benefit of the doubt.  (And there would still be a need for a separate program
to check for legal-but-questionable things.)

>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.

That's a job for the standards committee to resolve.

>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".

It's questionable whether it's okay to ignore the result from functions that
actually have an error return (though strcpy() is certainly safe).

>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).

I don't think I've ever needed that myself, but it's a reasonable request,
easily supported with a new lint-pragma.

Karl W. Z. Heuer (ima!haddock!karl or karl at haddock.isc.com), The Walking Lint