Choosing a static code analysis tool

Question

I'm working on a project where I'm coding in C in a UNIX environment. I've been using the lint tool to check my source code. Lint has been around a long time (since 1979), can anyone suggest a more recent code analysis tool I could use ? Preferably a tool that is free.

Answer 1

For C code, you definitely should definitely use Flexelint. I used it for nearly 15 years and swear by it. One of the really great features it has is that warnings can be selectively turned off and on via comments in the code ("/* lint -e123*/"). This turned out to be a powerful documentation tool when you wanted to something out of the ordinary. "I am turning off warning X, therefore, there is some good reason I'm doing X."

For anybody into interesting C/C++ questions, look at some of their examples on their site and see if you can figure out the bugs without looking at the hints.

Answer 2

Don't overlook the compiler itself.

Read the compiler's documentation and find all the warnings and errors it can provide, and then enable as many as make sense for you.

Also make sure to tell your compiler to treat warnings like errors so you're forced to fix them right away. ("-Werror" on gcc)

Also: "-Wall" on gcc does not enable all warnings, don't be fooled.

Also also: check out valgrind (free!) - it "automatically detect[s] many memory management and threading bugs, and profile[s] your programs in detail."

Valgrind isn't a static checker, but it's a great tool! http://valgrind.org

Answer 3

I've heard good things about clang static analyzer, which IIRC uses LLVM as it's backend. If that's implemented on your platform, that might be a good choice.

From what I understand, it does a bit more than just syntax analysis. "Automatic Bug Finding", for instance.

Answer 4

We've been using Coverity Prevent to check out C++ source code.

It's not a free tool (although I believe they offer free scanning for open source projects), but it's one of the best static analysis tools you'll find. I've heard it's even more impressive on C than on C++, but it's helped us avoid quite a number of bugs so far.

Answer 5

There is a "-Weffc++" option for gcc which according to the Mac OS X man page will:

Warn about violations of the following style guidelines from Scott Meyers' Effective C++ book:

[snip]

I know you asked about C, but this is the closest I know of..

Answer 6

You might find the Uno tool useful. It's one of the few free non-toy options. It differs from lint, Flexelint, etc. in focusing on a small number of "semantic" errors (null pointer derefs, out-of-bounds array indices, and use of uninitialized variables). It also allows user-defined checks, like lock-unlock discipline.

I'm working towards a public release of a successor tool, Orion (hopefully before the end of the year).

Answer 7

lint is constantly updated... so why would you want a more recent one.

BTW flexelint is lint

Answer 8

Lint-like tools generally suffer from a "false alarm" problem: they report a lot more issues than really exist. If the proportion of genuinely-useful warnings is too low, the user learns to just ignore the tool. More modern tools expend some effort to focus on the most likely/interesting warnings.

Answer 9

G'day,

I totally agree with the suggestions to read and digest what the compiler is telling you after setting -Wall.

A good static analysis tool for security is FlawFinder written by David Wheeler. It does a good job looking for various security exploits,

However, it doesn't replace having a knowledgable someone read through your code. As David says on his web page, "A fool with a tool is still a fool!"

cheers,

Rob

Answer 10

I recently compiled a list of all the static analysis tools I had at my disposal, I am still in the process of evaluating them all. Note, these are mostly security analysis tools.

• splint
• RATS
• SMATCH
• Uno

Answer 11

PC-lint/Flexelint are very powerful and useful static analysis tools, and highly configurable, though sadly not free.

When first using a tool like this, they can produce huge numbers of warnings, which can make it hard to differentiate between major and minor ones. Therefore, it is best to start using the tool on your code as early in the project as possible, and then to run it on your code as often as possible, so that you can deal with new warnings as they come up.

With continual use like this, you soon learn how to write your code in a way which confirms to the rules applied by the tool.

Because of this, I prefer tools like Lint which run relatively quickly, and so encourage continual use, rather than the more cumbersome tools which you may end up using less often, if at all.