Which type of checker to create: KAST or Path?
Klocwork supports two different types of custom checker: those written against the Klocwork abstract syntax tree (KAST) and those written against the intermediate representation (Path).
KAST checkers are useful for finding syntax-related oddities or idioms that you wish to control, for example as part of a style or coding guideline. KAST checkers operate against the abstract syntax tree that the Klocwork compiler generates from a source module, and work by searching that tree in a hierarchical fashion to locate code constructs that are to be reported. KAST is an XPath-like domain-specific language that provides operators and functions that support the construction of declarative statements identifying the appropriate part of the syntax tree. Klocwork's Checker Studio can be used to prototype KAST expressions and provides a fast way to create KAST checkers.
If a KAST checker requires conditions that aren't available through Klocwork's standard built-in functions, you can create custom functions by using a simple C API. Once the function is coded, you simply call it in your KAST expression and specify the name of the library that contains the function in your checker definition . For a list of built-in functions, open Checker Studio, and go to Help > Help topics > KAST reference > C/C++ KAST built-in functions reference.
Path checkers search for control-flow and data-flow issues, including interprocedural flows. Path checkers operate against an intermediate representation of the code that is called MIR. This structure is like a flowchart, in which each function in the source is represented by a control-flow graph composed of MIR nodes, each node encoding an operation in first order logic and a potential set of incoming and outgoing edges. Path checkers must be written in C++, and follow the control-flow paths through the MIR, searching for the defect you've identified. A typical Path checker tracks a value from a source (a starting point for analysis) to a sink (the end point where the defect is detected), using the source and sink 'trigger' points you specify.
If you want more information about creating Path checkers, contact Static Code Analysis Professional Services.