Do Static Source Code Analysis Tools Really Work? 345
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 (Score:3, Funny)
Yes! Uh, sorta. (Score:4, Funny)
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 (Score:3, Funny)
Infinite loop detector (Score:1, Funny)
eventually halt or not for a given input? I'd pay big money for that!
Re:Linux kernel devs use sparse for static analysi (Score:3, Funny)
Doesn't do me any good (Score:1, Funny)
I second valgrind (Score:5, Funny)
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 (Score:2, Funny)
Re:In Short, Yes (Score:1, Funny)
I am perfect you insensitive clod!
Re:In Short, Yes (Score:5, Funny)
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 (Score:3, Funny)