open source

Editor: Christof Ebert ■ Alcatel ■ [email protected]

Static Code Analysis

Panagiotis Louridas

W
ool has a tendency to collect static (perhaps even training) to do the work right.
electricity and thus to attract dust It’s therefore impossible to use them on a pro-
and lint. Developers know that pro- ject’s complete code base.
grams have a similar tendency to Moreover, the earlier we find bugs, the eas-
attract defects and, furthermore, ier it is to fix them. Ideally, we would like to
that many of them aren’t visible to catch errors when we make them, or as close
compilers. In the 1970s, Stephen Johnson, then afterward as possible, and not ipso facto with
at the Bell Laboratories, wrote Lint, a tool to reviewing or testing.
examine C source programs Most errors fall into known categories, as
that had compiled without er- people tend to fall into the same traps repeat-
rors and to find bugs that had edly. It’s exactly the predictability of people’s
escaped detection.1 fallibility that gives tools such as Lint a chance.
There are many ways to re- Lint worked by looking for known error pat-
duce the number of bugs in a terns. It didn’t try to execute the program and
program. Writing tests is one, compare actual with expected behavior, which
and tools such as JUnit help is the dynamic analysis that we do when we
programmers do this.2 Re- test. Instead, Lint trawled through the program
search tells us that code re- source trying to match patterns. Such tools are
views are probably the best called static checkers. They check our programs
way to eliminate bugs. Unfortunately, getting for errors without executing them, in a process
the right people together to study programs called static code analysis.
and identify problem areas in them takes a lot Programmers usually employ static checkers
of time. Code review teams also need practice after compilation and before testing. In this
way, they work with a program that has an ini-
tial indication of correctness (because it com-
piles) and try to avoid well-known traps and
Editor’s introduction pitfalls before measuring it against its specifica-
Bugs are disturbing. This holds in summer with the insect types and tions (when it’s tested). Static checking is rela-
year-round with the software types. While developers have long de- tively painless, although it can be humbling—
ployed reviews, inspections, and different testing strategies to find especially the first time. Lint’s success has given
software bugs, they don’t yet widely use the available semiautomatic today’s programmers many descendant tools,
defect-detection techniques. Panagiotis Louridas explains here how static both open source and proprietary, that target
code-analysis tools are used and what defects they can detect. As usual, different languages and operating systems.
the column compares several open source tools together with a commer-
cially available tool. They can help you reduce the number of bugs of all Static code checking in Java
the software types—security, memory, data typing, and so on—before To see static code checking in action, let’s
you deploy the more expensive verification techniques. start with the coding horror in figure 1. Al-
—Christof Ebert though this program compiles, it fails to do
what the programmer wants. The programmer
intends to read a string from the user, substi-

58 IEEE SOFTWARE Published by the IEEE Computer Society 0740-7459/06/$20.00 © 2006 IEEE
Authorized licensed use limited to: University of Groningen. Downloaded on May 14,2025 at 11:41:12 UTC from IEEE Xplore. Restrictions apply.
 OPEN SOURCE

1 import java.io.InputStreamReader;
2 import java.io.BufferedReader;
3 import java.io.IOException;
4
5 public class CodingHorror {
6
7 public static void main(String args[]) {
8
9 InputStreamReader isr = new InputStreamReader(System.in);
10 BufferedReader br = new BufferedReader(isr);
11 String input = null;
12 try {
13 input = br.readLine(); // e.g., peel
14 } catch (IOException ioex) {
15 System.err.println(ioex.getMessage());
16 }
17 input.replace(‘e’, ‘o’);
18 if (input == “pool”) {
19 System.out.println(“User entered peel.”);
20 } else {
21 System.out.println(“User entered something else.”);
22 }
23 }
24 }

Figure 1. A coding horror.

tute all “e” characters with “o” char- ■ Because strings are immutable in new string with the results of any re-
acters, then check whether the substi- Java, replace doesn’t modify the placements it carries out. The pro-
tution results in the string “pool.” This original string. Instead, it returns a gram simply ignores the result string
will never be the case, no matter what
input we provide.
To see why, we can use FindBugs
(http://findbugs.sourceforge.net), a pop-
ular open source static code checker for
Java, developed at the University of
Maryland. After running FindBugs on
the program in figure 1, we get the screen
in figure 2. It shows three possible bugs:

■ In the comparison at line 18 of the

source code, the == operator com-
pares object references, not the ob-
jects themselves. So, unless the two
strings we compare are stored in the
same object, the comparison will fail.
■ If, for some reason, the read opera-
tion at line 13 fails, input will be
null, and the program will try to call
the method replace on a null ob-
ject. (I must admit that, when prepar-
ing this example, I hadn’t planned
for this bug involving the use of a
possibly null pointer.) Figure 2. CodingHorror output in the FindBugs static code checker.

July/August 2006 IEEE SOFTWARE 59

Authorized licensed use limited to: University of Groningen. Downloaded on May 14,2025 at 11:41:12 UTC from IEEE Xplore. Restrictions apply.
 OPEN SOURCE

data-flow analysis, trying to infer the

Code Checker Resources possible values that variables might have
at certain points in the program. This is
For details on FindBugs, see “Finding Bugs Is Easy” by David Hovemeyer how, for instance, FindBugs found the
and William Pugh (ACM SIGPLAN Notices, Dec. 2004, pp. 92–106). In addition, second bug of our CodingHorror.
IBMdeveloperWorks has a two-part article on it (http://www-128.ibm.com/ Data-flow analysis is especially im-
developerworks/java/library/j-findbug1/, http://www-128.ibm.com/ portant for vulnerability checking—an
developerworks/java/library/j-findbug2/); the CodingHorror presented here is increasingly important area for code
inspired by similar snippets there. checkers. Whenever a program accepts
PMD Applied, by Tom Copeland (Centennial Books, 2005), describes PMD in input from a user, there’s a possibility
detail. (albeit remote) that a cracker can use
Diomidis Spinellis’s “Bug Busters” (IEEE Software, vol. 23, no. 2, 2006, pp. the input to subvert the system. Buffer
92–93) looks at code analysis tools from a wide software engineering perspective. overflows have been a cracker’s fa-
In any project, some modules are more critical than others; moreover, not all vorite inroad until recently, when SQL
bugs are worth fixing—a topic that Edward N. Adams addresses in “Optimizing injection seems to have overtaken the
Preventive Service of Software Products” (IBM J. Research and Development, vol. top place for program sore spots. In
28, no. 1, 1984, pp. 2–14). For a discussion of different ways to predict error- both cases, it’s important to be able to
prone modules and thus direct attention to them (for instance, conducting code trace the input flow from users through
reviews), see Christof Ebert and Ekkehard Baisch, “Industrial Application of Criti- the program.
cality Predictions in Software Development” (Proc. 9th Int’l Symp. Software Reli- No code checker can ever assure us
ability Eng. (ISSRE 98), IEEE CS Press, 1998, pp. 80–89). that a program is correct—such guar-
Piet Hein (1905–1996), a Danish poet and scientist with wide-ranging inter- antees aren’t possible. In fact, no code
ests, wrote short poems known as “grooks.” “The Road to Wisdom,” a grook checker is complete or sound. A com-
that Donald Knuth brought to the attention of the computer science community, is plete code checker would find all er-
always an elegant reminder: rors, while a sound code checker would
The road to wisdom? — Well it’s plain report only real errors and no false pos-
and simple to express: itives. The percentage of false to true
Err positives is an important indicator of a
and err code checker’s suitability for our pro-
and err again grams—it makes sense to examine a
but less checker’s behavior in our work before
and less committing to it in a whole project.
and less. Although code checkers rest on the
idea that human fallibility is somewhat
predictable, they can’t take all possible
bugs into account. Many checkers, in-
in line 17. The remainder of the pro- on the program source code and those cluding FindBugs, let programmers de-
gram continues to use the original that work on the compiled bytecode. fine their own rules for the checker to
string. This bug is arguably the most Each has its own advantages. When use. In this way, if developers know
subtle of the set. you work directly on the program that they’re particularly prone to some
source, your checking mirrors the ex- kinds of bugs, they can guard against
The example might seem contrived, act program code written by the pro- them by writing custom bug detectors.
but such bugs can wreak havoc on grammer. Compilers optimize code, Eliminating bugs doesn’t ensure
large projects, especially when dead- and the resulting bytecode might not high program quality. Many code qual-
lines loom and fatigue kicks in. In gen- mirror the source. On the other hand, ity metrics exist. Cyclomatic complex-
eral, static code checkers can find working on bytecode is considerably ity, a well-known one, assumes that
many kinds of bugs—FindBugs has faster, which is important on projects overly complex programs are difficult
more than 200 bug patterns. They’re containing more than a few tens of to maintain and more likely to contain
usually run as part of the build process, thousands of lines of code. errors.3 Among umpteen measures for
and their output comes in several for- Although each code checker works in object-oriented programs, Shyam Chi-
mats that users can view through a its own way, most share some basic damber and Chris Kemerer’s suite is
Web browser. traits. They read the program and con- the most widely cited.4 Special tools for
struct some model of it, a kind of ab- calculating such metrics exist, but code
Background stract representation that they can use checkers can implement some of them
Static code checkers in Java come in for matching the error patterns they rec- on the side. For other code-checker re-
two flavors: those that work directly ognize. They also perform some kind of sources and guidelines, see the sidebar.

60 IEEE SOFTWARE w w w . c o m p u t e r. o r g / s o f t w a r e
Authorized licensed use limited to: University of Groningen. Downloaded on May 14,2025 at 11:41:12 UTC from IEEE Xplore. Restrictions apply.
 OPEN SOURCE

Table 1
Static code checkers
Features FindBugs Checkstyle PMD Klocwork K7
Version 0.9.7 4.1 3.6 7.0.4.15
Works on Bytecode Source Source Bytecode and source
Languages Java Java Java Java, C++
Interface GUI, command line, plugin Command line, plugin Command line, plugin GUI, command line, plugin
Detects security vulnerabilities Few No Few Many
Stack overflow analysis No No No Yes (C++)
Custom checkers Yes Yes Yes Yes (C++)
Architectural analysis No No No Yes
Metrics No Few No Many
Web-based project management HTML reports HTML reports HTML reports Yes
Size 3.6 Mbytes 6.8 Mbytes 49.1 Mbytes (of which Depends on the configuration;
48.6 Mbytes is about 250 Mbytes for a
documentation) comprehensive Java installation
License GNU Lesser General Public GNU LGPL Berkeley Software Proprietary
License (LGPL) Distribution-style license

A bunch of code checkers at finding bugs for any given project. IEEE
Besides FindBugs, Checkstyle (http:// Table 1 compares four tools, but it’s
checkstyle.sourceforge.net) and PMD only a starting point.
(http://pmd.sourceforge.net/) are also

P
popular open source tools for Java. rogramming is arguably one of the
Checkstyle started as a tool for check- toughest jobs in project develop-
ing compliance with coding standards, ment. No machine can substitute
but it has evolved considerably and can for good sense, a solid knowledge of
now check for many coding problems. the fundamentals, clear thinking, and
PMD is similar to FindBugs, so it might discipline, but bug detection tools can FUTURE TOPICS:
be useful to try both and see what best help developers. In a recent article,5

Visit us
fits a particular project. Niklaus Wirth opined that “never do
The Klocwork K7 (www.klocwork. programs contain so few bugs as when
The Business of
com) suite is a proprietary solution no debugging tools are available.” Software Engineering
that works on bytecode to find defects
and security vulnerabilities and on
Caveat emptor.
onInspections
Software the
Web
References

web
source code to perform metrics and ar-
chitectural analysis. It therefore lets de- 1. S. Johnson, Lint: A C Program Checker, tech.
report 65, Bell Laboratories, Dec.1977.
Usability
velopers spot different kinds of prob- 2. P. Louridas, “JUnit: Unit Testing and Coding
lems at different detail levels. A license
for five seats offering full functionality
in Tandem,” IEEE Software, vol. 22, no. 4,
2005, pp. 12–15.
Internationalization
3. T.J. McCabe, “A Complexity Measure,” IEEE
for projects up to a half-million lines of Trans. Software Eng., vol. 2, no. 4, 1976, pp.
code costs US$19,975. 308–320.
All static code checkers I’ve exam- 4 S.R. Chidamber and C.F. Kemerer, “A Metrics
Suite for Object Oriented Design,” IEEE
ined let users filter the messages and Trans. Software Eng., vol. 20, no. 6, 1994,
warnings at different levels of sophisti- pp. 476–493.
cation. This feature is important be- 5. N. Wirth, “Good Ideas, through the Looking
Glass,” Computer, vol. 39, no. 1, 2006, pp.
cause false positives can be a big prob- 28–39.
lem; you need a way to reduce the
noise a wealth of warnings produces. Panagiotis Louridas is a grid software engineer at
the Greek Research and Technology Network and a researcher
Only comprehensive testing of the
at the Eltrun Software Engineering and Security research group www.computer.org/software
tools will give developers a clear idea of the Athens University of Economics and Business. Contact him
of how to optimize their potential at louridas@{grnet, aueb}.gr.

July/August 2006 IEEE SOFTWARE 61

Authorized licensed use limited to: University of Groningen. Downloaded on May 14,2025 at 11:41:12 UTC from IEEE Xplore. Restrictions apply.