开发者

Splint Code Analyzers for C [closed]

开发者 https://www.devze.com 2023-01-11 05:25 出处:网络
Closed. This question needs to be more focused. It is not currently accepting answers. Want to improve this question? Update the question so it focuses on one problem only by editing this
Closed. This question needs to be more focused. It is not currently accepting answers.

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

We are planning to use Splint as code analyzer for our C code base. But we never tried S开发者_StackOverflow中文版plint tool before so we want your input on it's benifts, pros and cons.


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


Read this blog post and these slides for a quick overview of what it can do for you.


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.


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.


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.

0

精彩评论

暂无评论...
验证码 换一张
取 消