Jump to: navigation, search


< CDT‎ | designs
Revision as of 22:08, 8 January 2010 by Elaskavaia.cdt.gmail.com (Talk | contribs) (Framework Parts)


To create a light-weight static analysis framework in CDT that allows to easily plug in "checkers" which would perform real analysis on the code to find common defects, violation of policies, etc.

Intended users of the "Codan" framework:

  • Tool Vendors
    • To create plugins containing end-user checkers and templates
  • Software Architects, Process Enforcement
    • To create customized new checkers, based on templates (no programming involved)
    • To create problems profiles
  • Developer, Tester, Code Inspector
    • To check for errors as you type and have a quick way to fix them, during development
    • To find bugs, security violations, API violations, coding standard violations during code inspection and before code run

Idea is to create a common components and API that are shared between static analysis tools for C/C++, such as:

  • User Interface to control the Problems enablement and parameters
  • Different launch modes (as you type, on demand, as a builder)
  • An eclipse View to display additional problem information (such as extra backtrace or more complex problem parameters)
  • A Generic Marker type for problems with extra fields
  • API to run log the problems
  • Base classes for checkers
  • Sample checkers
  • JUnit testing framework


any reportable item, such as error, warning, violation of any sort, and even search result
program that finds problems
False Positive
problem reported by checker which user considers as incorrect report (false)
False Negative
problem missed by checker which is a real problem of this type

User Experience

Code Analysis can be invoked in the one of the following ways:

  • Select a "Run Code Analysis" command from Navigator context menu (file, directory, project or combination)

Codan RunCodan.png

  • Enable "Run on Build" in Project preferences "C/C++ Code Analysis->Build", in this case it would be run with Incremental and Full Build

Codan RunOnBuild.png

User can control Severity and Enablement of Problems on Workspace level or on Project level.

Codan ProjectProperties.png

If Problems are found they would be displayed in the Problems view and has specific type, which can be grouped by or filtered out by the view controls.

Codan ProblemsView.png

Examples of possible Problems

  • Assignment in condition
 if (a=b) { ... }
  • Statement has not effect
  • Function name does not meet policy rules (should start with lowercase letter)
 void My_function() {}
  • Unused #include
 #include <stdio.h>
 int main() { return 1; }
  • Malloc called without sizeof consideration
 int * arr = (int *)malloc(20); // should be malloc(20*sizeof(int))

Create a Checker

To create simple checker you would have to extend one of the framework classes, and add extension point where you specify a class name and describe a problem, such as name, default severity, etc. Name would be visible on the Configuration page.

To create a checker:

  1. ) Define a problem(s) that you checker is capable of finding, cross check existing checkers to see if it is already there, create a bug report describing your intention to implement it
  2. ) Start coding:
    • check out all plugins from dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (use cdt checkout instructions) as separate eclipse projects
    • create a plugin for your checkers or use org.eclipse.cdt.codan.checkers
    • create an extension point for org.eclipse.cdt.codan.core.checkers. Specify one or more problem your checker would create with name, id, default severity and enablement
    • note: severity of the problem is user defined. If you creating a frontend for command line static analysis tool (such as lint) which can have different severity for same error, you have to create an id per severity per problem type. For example for "Null pointer dereference" you create npd.error and npd.warning ids. User may define both of them as warnings for IDE.
    • create a class in selected plugin which implements IChecker interface. You can pick default abstract implementation such as AbstractIndexAstChecker, see examples in org.eclipse.cdt.codan.checkers.sample
    • create a tests for your checker, it is pretty easy to do with existing framework see StatementHasNoEffectCheckerTest class as example
  3. ) Create a patch and attach to your bug

Extension Point

This is example of extension point:

           name="Assignment in condition">
           name="Assignment in condition">


API would contain:

  • Interfaces such as IProblem, IProblemCategory, IChecker, etc
  • Abstract class for checkers such as AbstractIndexAstChecker
  • Interface to call Report Logging
  • Interface to query status of problem enablement (for optimization purposes)

Current code resides in dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan


Current this framework is not packaged with CDT. To include it in your CDT based tool you need to manually export plugins located in dev.eclipse.org:/cvsroot/tools/org.eclipse.cdt/codan (can be done using export wizard) and add them to your distribution.

Future work

  • User defined checker's preferences, for example if it checkers for policy violations on function name let user specify name pattern using UI
  • Build shared models other than AST with bindings, such as Control Graph, Data Flow Graph (this was done in ptp project, maybe just bring it over)
  • Some common code to support Quick Fix for the problems
  • Common scope filters for checkers (excluded/included files)

Source & Bugs

Source located at


Send questions to cdt-dev list:


Send bugs to