It’s time to create a custom checker, but what kind?

on Nov 15, 11 • by Patti Murphy • with 1 Comment

You’ve been using source code analysis on your integration build or your desktop, or (ideally) both. And then there’s “a situation”. The situation Either you: Noticed a false negative you want detected, or Need a way to enforce a corporate coding standard, such as the requirement for the use...

Home » Static Analysis » It’s time to create a custom checker, but what kind?

You’ve been using source code analysis on your integration build or your desktop, or (ideally) both. And then there’s “a situation”.

The situation

Either you:

  • Noticed a false negative you want detected, or
  • Need a way to enforce a corporate coding standard, such as the requirement for the use of  a compound statement block rather than single statements as the body of a loop.

Now what?

Time to create a custom checker, that’s what. But what kind of checker?

Source code analysis involves two families of checkers, those that involve:

  • Abstract Syntax Tree (AST) validation, and
  • Code path analysis.

An AST provides a tree-based structural representation of the source code. An AST checker allows you to pinpoint problematic syntax using XPath or XPath-derived grammar to define the problem you’re looking for. AST checkers (our version is called Klockwork AST checkers, or KAST for short) don’t require program execution to run; they detect defects right away on source code.

Code path analysis, on the other hand, targets defects related to value tracking at program execution time. Instead of style violations, you’d use a path checker to answer questions such as:

  • Is this newly-created object released before all aliases to it are removed from scope?
  • Is this data object ever range-checked before being passed to an OS function?
  • Is this string checked for special characters before being submitted as an SQL query?

To create a path checker, you don’t need to know how data is tracked by the checker. What you do need to know are the function types and values you want to track for the analysis starting point and the analysis end point where the defect (or event) is recognized and reported.

Which checker when?

Create an AST checker when the problem you want to detect:

  • is a local defect
  • does not involve program execution
  • has to do with the way the program was written
  • does not involve tracking a value
  • does not involve a path

Create a path checker when the problem you want to detect:

  • involves tracking a value
  • has a starting point (where the analysis starts) and end point (where the defect is detected)
  • involves program execution

Stay tuned for the next post in this series on best practices for AST checker creation.

For more information, see Writing custom checkers with Klocwork Extensibility or check out our member discussions in the C/C++ custom checkers forum.

–With files from CTO Gwyn Fisher

Related Posts

One Response to It’s time to create a custom checker, but what kind?

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Scroll to top