Do Static Source Code Analysis Tools Really Work?

jlunavtgrad writes "I recently attended an embedded engineering conference and was surprised at how many vendors were selling tools to analyze source code and scan for bugs, without ever running the code. These static software analysis tools claim they can catch NULL pointer dereferences, buffer overflow vulnerabilities, race conditions and memory leaks. Ive heard of Lint and its limitations, but it seems that this newer generation of tools could change the face of software development. Or, could this be just another trend? Has anyone in the Slashdot community used similar tools on their code? What kind of changes did the tools bring about in your testing cycle? And most importantly, did the results justify the expense?"

Change bug source

[192939495969798999]

The best thing these tools can do is to tell everyone what they probably already know -- that a particular coder or coder(s) are responsible for a whole ton of the errors in the code. I think it'd be much better to move that coder to some other part of the company ... it would be way cheaper than trying to fix all their bugs.

Yes! Uh, sorta.

[BigBlueOx]

Ya can't beat a good "Lint party" after all the testing is done! You'll find all kinds of cool stuff that slipped through your testing suites.

However, static code analysis is just one part of the bug-finding process. For example, in your list, in my limited experience, I have found that buffer overflows and NULL pointer derefs get spotted really well. Race conditions? Memory leaks? Hmm. Not so good.

YMMV. Don't expect magic. Oh to hellwithit, just let the end-users test it *ow!*

Re:Static analysis tools

[somersault]

I suppose it depends if you are writing systems that can kill people if something goes wrong.

The best way to avoid bugs in that case would be for the developers to test the systems themselves - then they'd be a lot more careful! Plus it helps natural selection to weed out the sloppy coders :) In that case you'd probably want to write all the code from scratch though to ensure that nobody else's bugs kill you.

Infinite loop detector

[nuttyprofessor]

How about a tool that will tell me if my program will
eventually halt or not for a given input? I'd pay big money for that!

Re:Linux kernel devs use sparse for static analysi

[ncw]

s/Linux Torvalds/Linus Torvalds/ - I keep making that typo ;-)

Doesn't do me any good

[Anonymous Coward]

Static analysis tools never work for me, I don't declare anything static.

I second valgrind

[jberryman]

There's also valgrind, for Linux users

It's great for finding all those elusive bits of code that might be accidentally seeding a pseudo-random number generator somewhere.

Re:In Short, Yes

[Anonymous Coward]

That's what all the useless people say.

Re:In Short, Yes

[Anonymous Coward]

You don't need to be perfect to be useful.

I am perfect you insensitive clod!

Re:In Short, Yes

[neokushan]

I hope you realise I just spent a good 2mins googling around for an explanation of a for loop with 4 parts to it instead of the 3 I was used to seeing. I genuinely thought it was some special, relatively unknown and underused part of the C spec that I'd just not seen before.
Then I realised it was just the HTML screwing up a less-than symbol. Then I felt a bit silly.
Then I just had to tell someone....

Re:In Short, Yes

[poopdeville]

A program that depends on Goldbach's conjecture for its validity over all inputs isn't particularly absurd. Have you never written a program that decomposes natural numbers into a sum of primes? Never? Wow, you must write pretty boring programs. Additive prime decomposition is a straightforward way to partition a space for combinatorial problems.