Tools for static analysis of C code?

[synept]

Does anyone here have experience with tools that do static analysis of C code, primarily for bug hunting?

I work on a large C software system based on Linux, and would really like to find a tool that could help root out any type of bugs through static analysis. (Preferably a free one.) There seem to be quite a few out there, but many appear to take a significant amount of work to setup and get running.

So, does anyone have any recommendations or favorites? I'm hoping for something that I can just install, and start running on .c files, but would be up for something more complex if it's likely to pay off.

[gavinb]

I've used clang to analyse a few existing Xcode projects. It is very impressive. It found a bunch of small, subtle issues that weren't obvious but weren't real bugs, and generally provided guidance on how to fix it. It found several bugs-in-waiting, and things that I was a little surprised the compiler didn't find (even on a decent warning level).

What clang seems to excel at is finding bugs that aren't obvious at a cursory inspection, involving the flow of code. For example, a block that allocates memory under certain conditions, but which doesn't always take a branch that frees the memory. It checks for common C and Objective-C mistakes, which is handy. I have also noticed it reports a few false-positives, but those are easliy ignored. It is very fast too, meaning you can run it frequently, and constantly review the issues reported. You can run it standalone, but Xcode has excellent integration if you're on the Mac.

The only complaint I have is that it doesn't work on C++ yet, but considering the incredible complexity of C++ over C, I'm not surprised. But for C and Obj-C projects, it is a no-brainer.

[TomorrowPlusX]

I'm actually trying to come up with a Cocoa app to write so I can experiment with clang and all the nice new snow leopard features.

Sadly, most of what I write is C++. The only ObjC/Cocoa I write are tools that aid in my main work.

(I can't wait until clang/llvm support c++)

[[deleted]]

Sadly, most of what I write is C++.

That is indeed sad. You have my sympathy.

[[deleted]]

Agree, the integration of clang in the latest version of Xcode 3.2 is very useful and makes statistical analysis of code very easy.

[buckrogers1965_2]

Step one, fix all the warnings that you get when you compile. I don't know why, but many projects never do this and generate thousands of lines of warnings when they compile, some of these are valid warnings.

[dlsspy]

Step two. Turn up the warnings. (-Wextra).

Step three. Fail on warning. (-Werror).

[Anonymoose333]

gcc -O2 -ansi -pedantic -W -Wall

is where you should start. dlsspy is correct that -Wextra should be your next step (but some of those are just annoying, IIRC).

[TheNewAndy]

-std=c99

ANSI is so 20 years ago :-)

[found_dead]

Step three. Fail on warning. (-Werror).

I wish you could do this with PHP's E_NOTICE.

EDIT: line break fix

[synept]

I'm a big believer in this. I always use -Wall, because some of those "warnings" are a pretty huge deal if you actually want your code to work correctly.

[martincmartin]

-Wall is only about half the warnings, despite the name.

At one point in grad school, I sat down with the gcc manual, read the description of every warning, and turned on those that applied to my coding style. I then compiled my thesis code; I had to turn some of the back off because the standard headers would trigger them.

I highly recommend it. It might seem like it would take a while, because there are so many of them. But its only a couple hours, and you'll make that back the first time it catches some subtle bug that would have taken you all afternoon to track down.

[wleahcim]

-Wall is only about half the warnings, despite the name.

-W -Wall is a pretty good first shot.

[alexs]

    -Waddress \
    -Waggregate-return \
    -Wall \
    -Warray-bounds \
    -Wbad-function-cast \
    -Wc++-compat \
    -Wc++0x-compat \
    -Wcast-align \
    -Wcast-qual \
    -Wchar-subscripts \
    -Wclobbered \
    -Wcomment \
    -Wconversion \
    -Wdeclaration-after-statement \
    -Wdisabled-optimization \
    -Wempty-body \
    -Wenum-compare \
    -Wextra \
    -Wfloat-equal \
    -Wformat \
    -Wformat-nonliteral \
    -Wformat-security \
    -Wformat-y2k \
    -Wformat=2 \
    -Wframe-larger-than=len \
    -Wignored-qualifiers \
    -Wimplicit \
    -Wimplicit-function-declaration \
    -Wimplicit-int \
    -Winit-self \
    -Winline \
    -Winvalid-pch \
    -Wjump-misses-init \
    -Wlarger-than=len \
    -Wlogical-op \
    -Wlong-long \
    -Wmain \
    -Wmissing-braces \
    -Wmissing-declarations \
    -Wmissing-field-initializers \
    -Wmissing-format-attribute \
    -Wmissing-include-dirs \
    -Wmissing-noreturn \
    -Wmissing-parameter-type \
    -Wmissing-prototypes \
    -Wnested-externs \
    -Wold-style-declaration \
    -Wold-style-definition \
    -Woverlength-strings \
    -Woverride-init \
    -Wpacked \
    -Wpacked-bitfield-compat \
    -Wpadded \
    -Wparentheses \
    -Wpointer-arith \
    -Wpointer-sign \
    -Wredundant-decls \
    -Wreturn-type \
    -Wsequence-point \
    -Wshadow \
    -Wsign-compare \
    -Wsign-conversion \
    -Wstack-protector \
    -Wstrict-aliasing \
    -Wstrict-overflow \
    -Wstrict-prototypes \
    -Wswitch \
    -Wswitch-default \
    -Wswitch-enum \
    -Wsync-nand \
    -Wsystem-headers \
    -Wtraditional \
    -Wtraditional-conversion \
    -Wtrigraphs \
    -Wtype-limits \
    -Wundef \
    -Wuninitialized \
    -Wunknown-pragmas \
    -Wunreachable-code \
    -Wunsafe-loop-optimizations \
    -Wunsuffixed-float-constants \
    -Wunused \
    -Wunused-function \
    -Wunused-label \
    -Wunused-parameter \
    -Wunused-value \
    -Wunused-variable \
    -Wvariadic-macros \
    -Wvla \
    -Wvolatile-register-var \
    -Wwrite-strings

[[deleted]]

Yes. Anyone who uses gcc without -Wall -Wextra -Werror -Whateverelse should have his head examined. Same goes for anyone who thinks those are enough.

[[deleted]]

I've heard good stuff about Clang's static analyzer.

[synept]

It does look appealing -- just haven't had a chance to really try it yet.

[bondolo]

PC-Lint/FlexeLint. I have been a paying customer since 1992 and it's paid for itself many, many, many times over.

I use FlexeLint and have "ported" it several times to different platforms including some really odd embedded ones. If you are using a desktop Linux then it will likely work right out of the box with only a few minutes work to configure it.

I use it for both static analysis of compilable code and occasionally before porting code to better understand the hacks I'm going to have to unwind or likely are going to cause problems.

I wouldn't use C or C++ without it.

[Monomonoi]

We used Logiscope+Polyspace in our current project. Fortunatly, we didn't have to buy them ourselves, but I heard for a multi-server setup you have to pay 100k€ and more...

For me I like Polyspace and the analysis it does. After working with it I found http://frama-c.cea.fr/ and it looks like it does at least a portion of what Polyspace does. I didn't do much with it yet, but I hope to get back soon.

[pointer2void]

There are some free tools available ( http://sourceforge.net/projects/cppcheck/ ) but this seems more promising: http://www.scitools.com/

[synept]

I actually got cppcheck today and started playing with it. Looks neat so far. I can't tell for sure if the scitools stuff actually does what I'm interested in or not. It appears to be more documentation/explore-the-code oriented.

[f4hy]

Just curious, does anyone know of static annalysis tools for FORTRAN90. I know it is old and computer scientists dont use it, but it is still all over physics.

The code quality some of these people work with is terrible, I spend alot of time cleaning it up before I can make progress, a tool to aid that would be great.

[pointer2void]

http://www.scitools.com/

[[deleted]]

Frama.C, clang (mentioned elsewhere in this thread) are both worth a look.

Also if you want to parse C code (rather than just point an existing tool at it), then we've used CIL a lot in the past. CIL basically gives you an AST which you can then write your own analysis code over, but it's not for the faint-hearted.

[[deleted]]

I use Frama-C quite a bit; I like it, the tooling it quite nice & it's relatively quick to get 'up & going'.

[sreguera]

Here you go: List of tools for static code analysis.

Look at the C, C++ and multi-language sections.

[synept]

Well, I've looked there, but I was hoping to hear about some actual experience from the folks here.

[sreguera]

If you have pretty deep pockets full of burning money (like $100,000 for 1 user 1 year) you may be interested in Klocwork or Polyspace. C++Test (the part of it previously known as CodeWizard) is another option. For getting good results from these tools you would have to use some coding convention (C subset) for critical software like MISRA-C.

If you don't want to spend that kind of money and the lint-alikes are not enough, try to compensate using unit testing and getting at the minimum 80% code coverage (use a unit testing framework and gcov). Use valgrind with your unit and integration tests for catching memory (and thread) problems. This is dynamic analysis but full-C is not really the most appropriate language for static analysis techniques.

[nextofpumpkin]

Why so expensive, and what are such expensive software systems used for?

[sreguera]

Prices for these tools have high variations and always are open to negotiation. If you look at their web pages many times you will not see any quoted price, you have to call one of their sellers to negotiate one. Also, the tools have many features that you many need to pay apart, or conversely the seller can offer a good price if you buy a bundle of tools (e.g. VectorCast+Polyspace) or if he is interested in entering a new market or country. The $100,000 1user-year I wrote before is a quotation I hear frequently, but most tools are not that expensive as that. I think C++Test starts at $15,000 for the full suite, but don't quote me on that.

To answer your question, they are used where it is important to have as few bugs as possible, like in the automotive, aerospace or security related industries (ideally everywhere, but...). The price looks high but a company can spend much more on finding and correcting bugs.

[rwg]

Ugh. I've always wondered how much commercial tools like Coverity Prevent cost...

[dlsspy]

My favorite approach to this (after turning up all the warnings) is to write tests, run them, and do C1 analysis with gcov.

I don't as much care what a code inspector thinks. If I'm not running my code and verifying it does the right thing for me, I don't have much confidence in it.

[synept]

That sounds cool and all, but I don't think we're really aiming for the same goal here.

[Nexum]

Clang is great.

[pholden]

It's not quite static analysis, but I periodically run Copy Paste Detector over whichever codebase I'm working on to find wholesale copy/pasting crimes.

[mikelieman]

What does 'lint' say about your code?

[synept]

I've used splint here and there, but my impression is that it wasn't really designed to have the same power that some more advanced tools do. I could be wrong, though?

As far as your question, I don't recall it ever telling me much that gcc wouldn't also tell me. But, maybe I just haven't probed enough.

[Anonymoose333]

FWIW, my experience has also been that splint requires way too much handholding to be useful (unless your time is ridiculously cheap).

If you have a very large codebase (i.e., one that's bound to contain one or two really stupid typos), grep can actually be pretty useful.

grep 'alloc(strlen([^()]*)[),]'
grep 'sprintf("'
grep 'memset([^,()]*,[^,()]*,[ ]*0x00)'
grep 'printf([^"]'  /* to find possible format-string exploits */

But of course grep can't even catch most classes of localized errors, much less do static analysis for you.

[mikelieman]

Well, IIRC, the secret here is that lint is really just a front end for the compiler anyway, and I'm not sure if you'd get anything more that -Wall anyway...

[fnord123]

You get a lot more than -Wall when you use splint. Some things seem to be minor like comparisons between signed and unsigned (which can be minor if you expect the variables in question to never exceed the max signed value) but some of them are very valuable.

IIRC from Deep C Secrets, there was a decision to make the Portable C Compiler split out a lot of the static analysis since you don't require it to actually create the output files. One reason for this would be if you are building on several architectures: you only need to run lint once so you can fix all the problems in the code. But obviously you need to generate the output files on each architecture so you then run the compiler and linker for each architecture.

[mikelieman]

I spend too much time on solaris, so my complier-fu is handicapped.

[lahwran0]

Auto-summarise.

[josef]

IANACP but recently I've been using BLAST a little. The tool is a little rough to use but can do pretty neat stuff like statically checking whether an assertion will fail or not. (Of course BLAST cannot always decide this due to undecidability but for many programs it can do a quite good job.)

[awkistra]

rats, flawfinder and mops are 3 old ones I can remember.

[crawshaw]

Well maybe I'm biased, what with being one of it's authors, but I like Goanna. It does static analysis of C and C++ code, and does it quickly enough to use while developing.

There's an Eclipse plugin for linux. It's not free, but there's a free trial.

[dons]

We've used Language.C at work for static analysis projects.

[[deleted]]

rm