Static code analyzers for C

Question

Which static code analyzer (if any) do you use? I've been using PyLint for Python and I'm pretty satisfied with it, now I need something similar for C code.

How much of it's output do you have to suppress for normal daily usage?

Answer 1

I used PCLint forever and really liked it. I wish they'd get into C#... They are the ones with the pop quizzes on C or C++ code in all the magazines.

Answer 2

There's splint, although, to be honest, I've never been able to get it to work; on my platform, it really is too overactive. In practice, my most-used "lint" are the following warning flags for gcc

-std=c89 -pedantic -W -Wall -Wstrict-prototypes -Wunreachable-code  -Wwrite-strings -Wpointer-arith -Wbad-function-cast -Wcast-align -Wcast-qual

Of course, I've mostly forgotten what half of them mean. But they catch quite a few things.

Answer 3

Wikipedia maintains a list of static code analysis tools for various languages (including C).

Personally, I have used both PC-Lint and Splint. The best choice depends on the type of application you have written. However no matter which tool you use, there will be a low signal to noise ratio until you properly tune the tool and your code.

PC-Lint is the most powerful Lint tool I used. If you add it to an existing project, the signal to noise ratio can be low. However, once the tool and your code are properly configured, it can be used as part of your standard build process. The last major project where I used it, we set it so that PC-Lint warnings would break the build. Licenses for PC-Lint cost $389, but it is worth the cost.

Splint is a great open-source tool. I have used it on several projects, but found that it can be difficult to configure when using a compiler with non-ANSI C extenstions (e.g. on embedded systems projects).

Valgrind is also worth considering as a dynamic analysis tool.

---

You specifically requested feedback on SourceMonitor. This tool provides interesting metrics on your code, but should be used as a supplement to good Lint tool as it does not provide that kind of analysis.

As stated on their home page, SourceMonitor will:

...find out how much code you have and to identify the relative complexity of your modules. For example, you can use SourceMonitor to identify the code that is most likely to contain defects and thus warrants formal review.

I used it on a recent project and found it to be easy to use (even for embedded systems code). The complexity metric is an excellent resource for developing code that will be less error-prone and easier to maintain.

SourceMonitor provides nice graphs of its output as well as well-formatted XML if you want to automate metrics collection. The only downside is that the tool only runs on Windows.

Answer 4

There is one in the llvm clang project http://clang-analyzer.llvm.org . I have not tried it myself but i intend to do it.

It looks pretty good in action: http://www.mikeash.com/?page=pyblog/friday-qa-2009-03-06-using-the-clang-static-analyzer.html Above is for Objective-C but it should be the same for C.

Answer 5

We use PC-Lint and are very happy with it.

There seem to be a few camps regarding message suppression and tuning:

• suppress everything, then unsuppress only what you're interested in
• unsuppress everything, then suppress warnings you're not interested in
• keep everything unsuppressed

We tend to fall somewhere between the second and third categories. This does mean a ludicrous 100MiB+ text dump (one error per line) per lint run across the core libraries (lots of old code).

A custom diff-like tool watches for changes and emails those out to the commit's author, which keeps the amount that most people have to look at down to a few lines. We gather interesting statistics about errors-over-time with some basic data mining.

You can get really polished here, hyperlinking the errors back to more detailed descriptions, providing "points" for fixing existing warnings, etc...

Answer 6

I'm a big fan of David Evans's work on LC/Lint, which has apparently had its name changed to Splint. It is very aggressive, and you can tell it a lot of useful information by adding annotations to your code. It is designed to be used with programmer annotations. It will function without them, but if you try to use it as a simple checker without providing any annotations, you will probably be disappointed. If what you want is totally automated checking, and if you can deal with a Windows-only tool, you're better off with Gimpel's PC-Lint. Jim Gimpel has had happy customers for over 25 years.