ONLINE
Global news for the creators of technology
Static analysis stomps on bugs
By Richard A. Quinnell
March 6, 2008
Static source code analysis tools have
evolved from simple syntax checkers to
powerful tools for identifying flaws in the
complex interactions of large code bases.
Until recently, however, they were mainly
used by quality assurance teams to evalu-
ate code during integration builds near
project completion.
The latest product introductions are now
moving these tools back into the hands of
developers to help detect software errors
much earlier and before they propagate.
Klocwork’s Insight and GrammaTech’s
CodeSonar Enterprise both address devel-
oper needs by providing utility even when
many code segments are still missing.
Software development teams have two
. O
N F
types of tools available for automating the
IO Y
detection of errors in their code. One type
T P
U O
uses dynamic analysis, which watches
IB C
code as it is being executed. The other
R D
type uses static analysis, which algorithmi-
T TE
cally examines code for errors. Both types
D RIN
have advantages and limitations.
P
IS
Dynamic analysis is good at finding run-
time errors such as resource leaks and
dynamic memory corruption. Developers
can also be certain that any errors a
dynamic analysis tool reports are real,
because they were found during actual
code execution.
But to use dynamic analysis effectively,
the code must be thoroughly exercised,
which requires the use of test cases. Thus,
the effectiveness of dynamic analysis at
finding errors depends on the quality of the
tests being run. Further, because dynamic
analysis tools work with running software,
they come into play only late in develop-
ment, when code is already written and
first being integrated.
Static analysis uses an algorithmic
approach to examine source code for
R
FO
errors, identifying problem
areas for programmers to
T
O
examine more closely. This
.N
algorithmic approach elimi-
LY
nates the need for test cases;
N
the algorithms alone determine
O
how effectively the analysis dis-
G
covers errors. But the approach
IN
also raises the possibility of
D
A
false identification: code
E
R
flagged as being in error that
L
will, in fact, execute correctly. If
A
N
they generate too many false
O
positives—exhibit low “preci-
S
R
sion,” in the tool vendors’
E
P
terms—static tools can over-
R
whelm users with follow-up
tasks, obscuring the real errors. expectations, only procedure, and so will
The two tool types are complementary in identify potential problems without bias.
that each excels at finding errors that
cause the other difficulty, but dynamic Forward in development cycle
analysis has seen more use among devel- Until recently, static source code analysis
opers. This is partly because early static tools were useful only late in the develop-
analysis tools were little more than syntax ment process, at the integration build
checkers that developers used to find rela- stage, when they had full access to all code
tively simple coding and style errors. segments. A number of recent releases,
In the last decade, however, static analy- however—including Klocwork’s Insight and
sis tools have become more productive as GrammaTech’s CodeSonar Enterprise—
research has yielded more-effective algo- have added features to put static analysis
rithms. They have gained an ability to iden- tools into the hands of developers for use
tify a host of subtle errors (see table on as code is still being generated.
back), many of which only manifest as exe- This new generation of static source code
cution problems during task interleaving in analysis tools utilizes the enterprisewide
a preemptive multitasking environment. software development environment to
One of the side benefits of the new static combine the efforts of development teams
analysis capabilities is the enhanced ability working on different parts of the same proj-
to find weaknesses in code that malicious ect (see figure). By allowing the peer-to-
users could exploit to circumvent security peer exchange of information regarding
safeguards. It is easy for developers to analysis scans of code segments, the tools
underestimate software security vulnerabil- gather the wider context needed for preci-
ity, because they expect code to be operat- sion in error detection.
ed normally. The algorithmic approach of This wider context, coupled with auto-
static analysis tools, however, has no matic modeling of missing code, quickly
 This early use of static analysis, however, basis. “Different teams are prepared to
must be handled with an understanding of accept different levels of false positives,” said
the limitations stemming from its partial GrammaTech’s Anderson. “A safety-critical
view of the code. “It is important to remem- project may be willing to tolerate a 10:1
ber that in the early stages of software false:true error report ratio, while for other
development, the tools are imprecise and projects a 50:50 ratio is a problem because
can miss interprocedural effects,” cau- of wasted time tracking down false errors.”
tioned Paul Anderson, vice president of K l o c w o r k ’s
engineering at GrammaTech. Fisher said,
Anderson added, however, that the “Some of our
results improve as the body of analyzed customers start
code grows. Frequent early use of static using the tool
analysis can also help train developers to on day one,
recognize weaknesses in their individual when the tool
coding styles and adapt their approach to starts relatively
prevent repeating the same types of errors. weak. They sim-
Because tools in this new generation are ply tolerate the
put to use by the entire project develop- extra false posi-
ment team, they can build a history of tives. Others
analysis results to help identify new prob- prefer to take

R
FO
lems as they arise. Klocwork’s Insight, for the cost of wait-
instance, saves data from each analysis ing for the archi-

T
O
run, allowing developers to track flagged tecture to be

.N
errors throughout the development cycle, fully developed,

LY
said Gwyn Fisher, the company’s chief even though

N
technical officer. then, the defect

O
The tool also allows authorized senior density is high.”

G
developers to tag errors as false positives
IN Ultimately, project teams must decide
or as irrelevant, Fisher added, so that for themselves how to balance the cost of
D
A

future analysis runs do not report them. false positives early in the process
E
R

This helps the development team concen- against the cost of finding and correcting
L

builds a sound basis for developers to trate on real errors and makes more visible errors late in the process. However teams
A
N

check their code against, even while the any newly introduced errors or ones that choose to handle static analysis, though,
O

project remains incomplete. Errors caught arise when interacting code sections are the tools have proven to be a valuable
S
R

at this stage are much easier and cheaper analyzed together. asset in finding code defects and securi-
E
P

to correct than those caught later in devel- ty weaknesses. Now that the tools are
R

opment. Further, catching errors early pre- When to go static back in the developers’ hands so defects
. O
N F

vents them from propagating through the How early in the development process and are found earlier, static source code
IO Y

system to affect the behavior of code how often to use static code analysis is a ques- analysis can help lower the cost of devel-
T P
U O

developed later. tion best answered on a project-by-project opment, as well.

IB C
R D
T TE
D RIN
P
IS

(#16348) Reprinted with permission from the March 6, 2008 online edition of Electronic Engineering Times. Copyright 2008 United Business Media LLC.
For more information about reprints from Electronic Engineering Times, please contact PARS International Corp. at 212-221-9595.