Path: utzoo!attcan!uunet!cs.utexas.edu!rice!sun-spots-request
From: duanev@mcc.com (Duane Voth)
Newsgroups: comp.sys.sun
Subject: Lint is your friend?
Keywords: software
Message-ID: <8808@brazos.Rice.edu>
Date: 12 Jun 90 22:00:26 GMT
Sender: root@rice.edu
Organization: Sun-Spots
Lines: 30
Approved: Sun-Spots@rice.edu
X-Sun-Spots-Digest: Volume 9, Issue 209, message 15

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