mouse@mcgill-vision.UUCP (der Mouse) (01/11/87)
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
karl@haddock.UUCP (01/16/87)
[Followups to comp.lang.c, unless other languages are discussed.] In article <593@mcgill-vision.UUCP> mcgill-vision!mouse (der Mouse) writes: >In article <4906@mimsy.UUCP>, chris@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@haddock.isc.com), The Walking Lint
michael@orcisi.UUCP (01/16/87)
If anyone is looking for "extended" type checking in a C compiler and has access to a PC, I suggest you try Microsoft's C compiler with the options -W2 -DLINT_ARGS. I think it does a thorough but not unreasonable job.