Updated: Never — Philip's Blog

I admit it: I'm a static analysis junkie. :-)

In addition to getting the FreeBSD Coverity builds into shape again (about which I'll have more to say again in a couple of days), I use FlexeLint fairly religiously on most of my code. Everyone should decide for themselves if running a lint is worth it but for myself, I can say with full confidence that it improves the quality of my code.

Of course, FlexeLint is fairly expensive if you don't have anyone to pay for it for you. There are free alternatives however, like splint or even the venerable xlint by Jochen Pohl or one of the ancient lints included with certain Unix operating systems I won't name.

Recently, Gimpel have released a new version of FlexeLint. One of the main new features in this version is thread analysis. It is nowhere near as thorough as Coverity (I wouldn't expect it to be), but it's remarkably good at checking for balanced locking -- every lock needs an accompanying unlock -- even across fairly tricky code paths.

Over the past couple of days, I've been setting the new version loose on some multithreaded code I wrote a while back (some of which has been fairly widely deployed with few reported bugs) and it has been finding some surprising issues. Surprising in the sense of how can this ever work?! even. Concurrency is a funny business.

If your only excuse not to run static analysis is fear of the copious output a first lint run generates, perhaps you should reconsider. That's often "only" a matter of proper configuration -- which admittedly is a bit of a black art.

Maybe the bugs of the month on Gimpel's website can turn you into a static analysis junkie too?