duanev@mcc.com (Duane Voth) (06/13/90)
From article <6207@brazos.Rice.edu>, by auspex!guy@uunet.uu.net (Guy Harris): > As soon as I saw "SPARC" and "semaphore", the neurons devoted to > remembering that certain illegal C constructs involving passing members of > unions to routines expecting the unions themselves started frantically > firing... > ... > "lint" is your friend; it points this out when run against your program: > > semctl, arg. 4 used inconsistently llib-lc(149) :: foo.c(38) Well, I'm having a bit of an emotional reaction to "lint is my friend". I would very much like to use the services of lint but I have a bit of a problem with wading through hundreds of lines of warnings about problems I don't care about, hunting for occasional lines like the one above. Does anyone know of tricks that can be used to selectively shut lint up about certain problems? 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. 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. Is there any help for those of us with good intentions? duane voth duanev@mcc.com {uunet,harvard,gatech,pyramid}!cs.utexas.edu!milano!pp!duanev
eggert@uunet.uu.net (Paul Eggert) (06/14/90)
In Sun-Spots 9:209:15 duanev@mcc.com (Duane Voth) asks: |Does anyone know of tricks that can be used to selectively shut lint up |about certain problems? | |For example; malloc() et.al... Try something like this: #ifdef lint char *lintalloc; # define talloc(T,n) (lintalloc = malloc(sizeof(T)*(n)), (T*)0) #else # define talloc(T,n) ((T*)malloc(sizeof(T)*(n))) #endif int *p = talloc(int, 100); /* example of use */ You can thus muzzle lint as selectively as you please, but don't overdo it!
guy@uunet.uu.net (Guy Harris) (06/15/90)
>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....