David --

Bounce to the mailing list if you think appropriate.

73 de Jeff

On Tue, Apr 16, 2002 at 09:29:36AM -0400, David Evans wrote:
> 
> 
> On Tue, 16 Apr 2002, Martin Roehrig wrote:
> 
> > Hello,
> >
> > I'm new to Splint and although I browsed through the whole manual and read about 
>half of it I still can't get an overview on how it
> > all works together. Could you please help me with the following questions and/or 
>point me to some HOWTO or technical overview?
> >
> > 1. What sorts of files (configuration, code description etc.) are used with Splint 
>and which are the corresponding file extensions?
> >
> 
> The easiest way to run splint is to just run it on your .c files (as shown
> in http://www.splint.org/manual/html/sec1.html).
> 

Hmmm, after using lclint/splint for several years, I still have the feeling
that I'm not getting an "overview" :-)

Here's what I do:

1) I put a template .splintrc in the current directory that reminds
me of the myriad switches that splint uses. You will need to edit the
first line to include whatever cc options you are using, particularly
include paths. Attached is a copy of my template, put in the current
directory. I add a small tidbit to my Makefile that looks like:
=============================================================
.PHONY: splint
splint:
        splint $(DEFS) $(INCLUDES) $(librpm_la_SOURCES)
=============================================================
so that I can run "make splint".  Substitute for $(librpm_la_SOURCES)
as appropriate, use "*.[ch]" if necessary.

2) I usually try to aim for a "strict" annotation level in
general, disabling specific checks. In order to get over the
wall of noise that splint throws up at the outset, the very first
thing I do is disable all the complaints. Do this by running splint,
and then abstracting the suggested options to disable.

Here's the toy script I run across splint output to extract all the
options that need to be disabled. Not perfect, but WORKSFORME.
=============================================================
#!/bin/sh
grep -- ' [+-][^ 0-9>=+-][a-z]*' \
 | sed -e 's,.* \([+-][^ 0-9>=+-][a-z]*\).*,\1,' | \
   sort | uniq
=============================================================
Disable the noise (for now) by adding the options to the .splintrc
file after "in progress".

3) Iterate on the disabled options, enabling by commenting out, and
adding annotations as necessary and appropriate. I usually explore
by enabling certain options, and then adding the number of complaints so
that I can estimate the effort involved in "fixing" certain classes
of problems efficiently.

>  You can also use separate specification files.  See
> http://www.splint.org/samples/db/index.html for a (somewhat obsolete)
> example of how to do that.  If you want to define your own annotations,
> you use an .mts file (see http://www.splint.org/manual/html/sec10.html).
> 
> The configuration file .splintrc (in the current directory, and then in
> your home directory) can be used to set flags.
> 
> > 2. When and in which sequence are those files used by Splint?
> >
> 
> The configuration and mts files are read first, then the specifications,
> then the code files are checked.
> 

BTW, is there any interest in starting to get splint annotations
added to "production" (i.e. widely used/deployed, like rdist) sources?

I've tried to send patches upstream, but the resistance is predictably
high. The only way that I can see to integrate splint annotations
widely is to develop splint "experts" and then to carefully negotiate
annotations with upstream maintainers. Any interest in formalizing
this effort?

HTH

73 de Jeff

-- 
Jeff Johnson    ARS N3NPQ
[EMAIL PROTECTED] ([EMAIL PROTECTED])
Chapel Hill, NC
=============================================================

# --> Add your CC options here
-DHAVE_CONFIG_H -I. -I.

+partial
+forcehints

-warnunixlib
-warnposix

+unixlib

-unrecogcomments        # XXX ignore doxygen markings

+strict                 # lclint level

# --- in progress

# --> Disable/enable the options you are currently annotating here.

# --- +partial artifacts
-declundef
-exportheadervar
-exportlocal

-enummemuse
-fcnuse
-typeuse
-varuse

# --- not-yet at strict level
-bitwisesigned          # pita
-elseifcomplete 
-exportconst
-exportfcn
-exporttype
-exportvar
-fielduse               # 1 occurence <bits/sigset.h>
-forblock               # tedious
-ifblock                # tedious
-incondefs              # <bits/{ipc,pthreadtypes}.h> heartburn
-matchfields            # <bits/ipc.h> heartburn
-namechecks             # tedious ANSI compliance checks
-ptrarith               # tedious

-compdestroy
-mustdefine
-shiftimplementation

-strictops
-strictusereleased
-whileblock             # tedious

# --- not-yet at checks level
-ansi-reserved
+enumint
-mustfree
-predboolptr
-usedef

# --- not-yet at standard level
-boolops
-predboolint
+boolint
+charint
+ignorequals
+matchanyintegral

Reply via email to