We are planning to use Splint as code analyzer for our C code base. But we never tried Splint tool before so we want your input on it's benifts, pros and cons.
5 Answers
Lint tools are useful for finding common problems and errors that code reviews tend to miss. My opinion is that you have nothing to lose when doing static code analysis. The only down side is that you might get a lot of false positives or warnings that might be unimportant (i.e. coding style recommendation). You just have to develop good filtering skills. Static analyzers might also not catch everything, but hey it is better than nothing.
Here is a white paper from the SANS institute that might interest you: http://www.sans.org/reading_room/whitepapers/securecode/secure-software-development-code-analysis-tools_389

- 4,159
- 10
- 39
- 63
-
1+1 for emphasizing *false positives*. Using Splint on un-annotated code is not really fun... – eckes Aug 01 '11 at 19:33
-
Splint has lots of flags and options to slowly turn up the checking. If you run it on a project that has never had it done before, there will be 10-20 headers/systemic project idioms to overcome. For instance, inline assembler, etc. Many of the 'false positives' are a code hygiene type issue. Ie, there is some other way to express the same thing that doesn't produce a warning. Often this actually has portability benefits that you might not realize. I do agree that 'false positives' or just an initial 'message overload' is an initial barrier to find real problems. – artless noise Aug 05 '19 at 15:21
Read this blog post and these slides for a quick overview of what it can do for you.

- 3,155
- 2
- 30
- 53

- 112,946
- 110
- 377
- 526
Splint excels at making your code more idiomatic (and therefore easier to read, for various compilers to parse, more portable, and easier to refactor). Splint can find subtle bugs such as implicit casts between ints and floats. Splint tracks down memory leaks and other security vulnerabilities.
Try it: splint hello.c
.

- 22,868
- 20
- 88
- 147
As waffleman suggested static analysers do produce a lot of false alarms. I have found Prevent to give better alarms than Sparrow. Those are two we use for static analysis.
An example of a typical false alarm and good alarm is:
bar (char **output)
{
*output = malloc(100);
}
foo()
{
char *output=NULL;
bar(&output)
}
In function bar it would report memory leak for the pointer output. In the function foo it reports NULL dereference when the function bar is called. But nevertheless its a choice between finding a true alarm between 100s of false alarms.
So we can find memory leaks which can be missed during code reviews. Prevent license is expensive and once a alarm is marked false it doesnt appear in the subsequent analysis. Hence you have to find if Splint does the same.

- 10,355
- 2
- 43
- 69
The tool looks for pattern that could possibly be errors. The advantage is that the tool may find latent bugs and the disadvantage is that it may find a whole bunch on false positives as well.

- 27,972
- 12
- 65
- 103