Dr. Dobb's Journal - March 2008 - (Page 27)

Figure 5: The body of get_type, showing that there is an error on line 30. Table 1 shows the number of test cases required to achieve full coverage for each coverage criterion, and example values required of the inputs. Clearly, achieving full coverage is nontrivial. What can make it extremely frustrating is if it is fundamentally impossible. If your program contains unreachable code, then you cannot even get full statement coverage, never mind decision or MCDC. Similarly, if your code contains redundant conditions (conditions that are either always true or always false), then you might achieve statement coverage, but not decision coverage. A developer may spend hours trying to develop a test case before it becomes evident that it is impossible. If you know going in that this is the case, then you don’t have to waste time on it. In Figure 3, the value of variable rest (which is an unaliased automatic integer) must be at least 3 by the time you get to line 12. The decrement means it is at least 2 at the comparison, so the condition never evaluates to false. The following line 13 is also redundant by the same reasoning, and appears in a different report. This is a fairly simple example, and many humans would have spotted this in a code review because all the relevant expressions are in the same vicinity. If the bodies of the conditionals had been larger or if the conditions themselves had been embedded in a function or a macro, then the weakness would not have been as easy to spot. However, the static-analysis tool would not have been fooled. These kinds of issues correlate well with bugs, too. Consider Figure 4, in which the column on the left shows the condition that cannot be satisfied: pb->type can never be equal to 3. This value comes from a call to get_type(); see Figure 5. The error is on line 30 and is clearly a typo—the programmer missed the final X. Conclusion Bugs are a plague on our profession and bad for business. That’s why advanced static-analysis tools should be in every programmer’s toolbox, and not just for safety-critical systems. They help find real errors, and reduce cost. DDJ March 2008 l www.ddj.com l Dr. Dobb’s Journal 27 http://www.faircom.com/go/?useDLD http://www.faircom.com/go/?useDLD http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - March 2008

Dr. Dobb's Journal - March 2008 Contents Hmmmm Alia Vox Developer Diaries Developer’s Notebook Social Networks and Software Development Conversations Detecting Bugs in Safety-Critical Code Change Code Without Fear Continuous Integration and Performance Testing Wt: A Web Toolkit Automating Release Notifications The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.