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

is NULL. Had this path been tested, it would definitely have resulted in a program crash. This little example illustrates a few key points about this kind of analysis: • It is interprocedural. It is aware of the call graph and which values can come back when a function is called. • It is path sensitive, and knows about the relationships between the variables, too. There are other paths where a call to that function returns NULL, and more where REG_NOERROR is passed back in err, but no other paths where both can happen simultaneously. This is important— an analysis that noted that the function could return NULL and then flagged all possible dereferences of the return value as errors would produce too many false positives. • The analysis is a whole program: It analyzes all the code at once, not just one file at a time. • Finally, it doesn’t require any extra input, either in the form of test cases or annotations. amount of risk they carry. A buffer overrun in a medical device may be life threatening, whereas a leak in a game controller that means it must be reset once a day is very low risk. The amount of risk determines the falsepositive rate that users are prepared to accept. In practice, we have found that for the serious class of flaws, such as buffer overruns and null pointer dereferences, users are often prepared to accept a false-positive rate of as much as 75–90 percent. For less risky classes, a false-positive rate of more than 50 percent is usually considered unacceptable. Figure 2: Snippet from the function called. False Positives It is trivially easy to write a static-analysis tool that finds all the bugs in your program—one that reports all lines as bugs satisfies this criterion. Similarly, it is trivial to write a tool that never reports a false positive—one that tells you that all lines are bug free will suffice. Obviously, neither tool is useful. The real measure of the effectiveness of a static-analysis tool is how well it simultaneously balances the false-positive rate with the false-negative rate. For almost all nontrivial programs, all serious staticanalysis tools that attempt to find bugs report some false-positive results, and none are capable of finding all of the bugs in such programs. Too many false positives means that you may spend too much time sifting through the chaff looking for the real bugs. This robs your development effort of resources that might be better-spent finding bugs through other methods. A high false-positive rate has a subtle psychological implication too: As it increases, users are less likely to trust the results, and are more likely to erroneously tag a true positive as a false positive. Different kinds of bugs merit different levels of effort to find, depending on the HD PHOTO N O W A V A I LA B LE F O R D O W N L O A D I S 4 0 - 6 0 % F A ST E R I N P I C TO O LS . Speed-optimized HD Photo libraries are now available within the PICTools Software Development Kit (SDK). Microsoft’s HD Photo offers higher image quality, greater preservation of data and advanced features for today’s digital imaging applications. It is a still image compression algorithm for continuous tone photographic images and features lossy, as well as lossless, compression, multiple colorspaces, a wide dynamic range, and extensive metadata support. PICTools SDKs contain low-level C libraries offering advanced image compression, decompression, and editing. Maximum code speed has been achieved through algorithm and machine code optimizations. Also available for .NET and ActiveX. Supported across: 32-bit Sun Solaris 32-bit and 64-bit Linux 32-bit and 64-bit Microsoft Windows IBM AIX Mac OS X Contact us for more information. W W W . P E G A S U S I M A G I N G . C O M Pegasus is a registered trademark of Pegasus Imaging Corporation in the United States. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. March 2008 l www.ddj.com l Dr. Dobb’s Journal 25 http://www.pegasusimaging.com http://www.pegasusimaging.com 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.