Channels ▼


Q&A:'Aha!' Moments and the Holy Grail

Gwyn Fisher is chief technical officer at Klocwork, a provider of static code analysis tools. He recently spoke with Dr. Dobb's editor-in-chief Jonathan Erickson.

Dr. Dobb's: What's the hard part of static analysis?

Fisher: There's a tipping point in using a static analysis tool, and it depends on finding that "aha!" moment as quickly as possible. This might be a bug you'd never have found yourself, or it might be an architectural recommendation that slipped past you. Whatever it is, it has to happen pretty quickly.

Dr. Dobb's: As a tool builder, how do you cope with new technologies?

Fisher: It might be a technology paradigm shift, such as multicore, it might be a new standard or a new de facto adoption of a framework such as Boost -- all of these form the core of what we invest in over time. Developers buy a static analysis tool because it finds bugs in their code. Anything else we do differentiates our approach from our competitors, but if we don't support their language, platform, or libraries, then the product isn't worth implementing.

Dr. Dobb's: Does parallelization make static analysis faster, better, more accurate?

Fisher: Yes indeed. Any competent analysis product can process nodes in the control flow graph that occur at the same level in the hierarchy in parallel. We provide both multicore parallelism as well as a multimachine parallelism, both of which can be used to scale the analysis task almost linearly across hardware resources.

Dr. Dobb's: When it comes to static analysis, what's the Holy Grail?

Fisher: What we're all working hard at is trying to actually completely solve the problem of static analysis. Today's commercial tools all work in an unsound model of analysis, whereby we claim to find some bugs in your code, and we don't -- and can't -- claim to find all the bugs in your code, and only the bugs in your code. Any tools -- mostly academic -- that perform sound analysis, and therefore claim to find all bugs in your code, do so at the cost of vast false positive numbers, upwards of 80% to 90%. Obviously that's not tractable for real usage, so the Holy Grail here is a technology that not only can find all bugs, but has zero percent false positive at the same time. ... But don't hold your breath.

Related Reading

More Insights

Currently we allow the following HTML tags in comments:

Single tags


<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags


<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

