Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!mcnc!philabs!micomvax!musocs!mcgill-vision!mouse From: mouse@mcgill-vision.UUCP (der Mouse) Newsgroups: comp.lang.misc Subject: Re: lint as a part of cc Message-ID: <593@mcgill-vision.UUCP> Date: Sat, 10-Jan-87 20:49:22 EST Article-I.D.: mcgill-v.593 Posted: Sat Jan 10 20:49:22 1987 Date-Received: Sun, 11-Jan-87 09:37:49 EST References: <3214@bu-cs.BU.EDU> <4900@mimsy.UUCP> <4906@mimsy.UUCP> Organization: McGill University, Montreal Lines: 34 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