Lint is your friend?

[Guy Harris]

>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....