Path: utzoo!attcan!uunet!cs.utexas.edu!rice!sun-spots-request From: auspex!guy@uunet.uu.net (Guy Harris) Newsgroups: comp.sys.sun Subject: Re: Lint is your friend? Keywords: Software Message-ID: <8948@brazos.Rice.edu> Date: 14 Jun 90 18:22:50 GMT Sender: root@rice.edu Organization: Sun-Spots Lines: 35 Approved: Sun-Spots@rice.edu X-Refs: Original: v9n209, Replies: v9n214 X-Sun-Spots-Digest: Volume 9, Issue 219, message 1 >Does anyone know of tricks that can be used to selectively shut lint up about >certain problems? Yes, write your code so that it doesn't generate as many errors, and then use "grep" to rip out the rest of them. >For example; malloc() et.al. return char * but guarantees alignment of >memory to a boundary compatible with the largest supported compiler data >type. This causes SPARC lint checking code to warn about "possible >pointer alignment problem" when there isn't any possible alignment >problem. Grep this one out. >Lint's pass 2 also produces an "arg. n used inconsistently" >message for every *alloc call making it even harder to spot real problems >like the above. Call *alloc enough times in your program and lint becomes >real obnoxious. Call *alloc enough times *with the argument cast to "unsigned int" or just "unsigned" if it doesn't already have that type* and it'll be a lot less obnoxious.... Once ANSI C - which finally acknowledges that the type of a function includes not only the type of its return value but the types of its arguments - becomes widely available, this will be less of a problem if prototypes for functions are in scope, as ANSI C-knowledgable compilers and "lint"s will be able to do the conversion if it's legal (and give you an error at *compile* time if it's not!) as it'll know the argument type that's expected. The nasty errors I've had "lint" catch for me have made it worth *my* while to go through the effort of fixing the less-nasty errors or wading through many of the complaints; yes, "lint" really *is* your friend, although it's more friendly if you treat it right....