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.
tanner@ki4pv.UUCP (01/16/87)
) There should also be a way to shut off lint complaints about non- ) portable code in just a small, known region (#ifdef MY_MACH_TYPE) Sure enough, there is. We use it here often enough for some obscure and non-portable library refs which shrink the final object code: #ifndef lint #ifdef MY_MACH_TYPE /* my rather lint-clogged 4 lines of crud */ /* with explanation of what's going on & why it's mach-dep */ #endif #endif -- <std dsclm, copies upon request> Tanner Andrews