RADE

C++ Source Checker

mkCheckSource Overview

Testing source code in the CAA V5 environment
Technical Article

Abstract

C++ Source Checker contributes to enhance the global quality objectives of CAA V5 application. Operating at the source stage in the application development cycle, early checking against C++ coding rules will ensure better stability and reduce defect. As for other RADE products, it operates on both NT and UNIX platform with the same characteristics.


Why should you use CSC ?

What is a static controller

CSC (C++ Source Checker) is a C++ static controller.

A static controller is an application which analyzes a program and tries to discover potential defects or logical errors without executing the program. Opposite to a dynamic control occurring while running the program (like mkodt for example ), CSC works on C++ source code. The analysis part is similar to the front part of a compiler, therefore CSC includes its own C++ parser.

[Top]

Positioning CSC in the development process

The development process

A part of the development process of an application can be summarized by the following chart:

A static controller should be used after compiling the program. It is interesting to notice that compilers themselves contain static controls (type checking, for example).

Benefits of using CSC

After compiling the program, running CSC can detect corrupting errors before dynamic tests. This insures a better way of programming, reducing development and debug time.

Most of the hits detected by CSC can not be detected by any other tool, except by a manual code review. CSC does quickly and automatically this job.

[Top]

Checked Rules

AddRef / Release rules

A set of rules are provided that help debugging easily and quickly Object Modeler (directly or indirectly implied by QueryInterface) memory leaks within tested code. Debugging memory leaks can be very time consuming, as CAA and COM architecture is very complex. This automatic detection addresses a major need for large application projects where pieces of code are re-used by different developers. As they don't always know when the memory reservation has been done, they may not (or forget to) Release it, which leads to potential memory crashes during the execution of the application.[1]

Pointer LifeCycle rules

Another aspect when checking sources is the ability to analyze discrepancies usage of C++ null pointers. Checking these rules ensures a better control on the number of core dump occurring during the execution of the application.[2] [3]

Forbidden constructions rules

Some constructions, due to migrations, are deprecated, and others, due to specific Object Modeler rules, are forbidden. These rules consist in lists of prohibited identifiers, calls of methods, uses of classes or interfaces ...[4]

Callbacks rules

Using Callbacks in CAA implies using function pointers with a cast. These casts may be dangerous cause the compiler does not check if the function pointer meets the specification required by the soft. CSC checks the signature of the function passed to the callback method in order to prevent runtime crashes.[5]

Exceptions rules

Some methods provided by CAA can, depending on the context, throw an exception. CSC reports the usage of these methods if the exception is not handled by the user code, thus preventing a potential application crash at runtime. This check is close to the "exception not caught" compilation error generated by any java compiler.[6]

C++ rules

Some basic C++ programming rules are checked by CSC, like a correct usage of allocation/de-allocation routines.[7]

[Top]

Architecture in brief

CSC provides its own C++ source parser. It ensures that sources are well checked against the provided rules. The parser acts as a front task compiler, it generates the syntax tree of the source, creates the symbol table [8]. Multiple sources and frameworks checking can be handled across different workspaces, thus taking into account potential external prerequisite frameworks.

[Top]

How to use

CSC works only on CAA File Trees (CAA source files are managed and delivered in components whose structure respects a particular organization). Though compilation step is not required, it is strongly recommended. Indeed, CSC works as a front task compiler, but without reporting compilation errors. The C++ parser will not run accurately if the source contains build errors ; no error or message indicating that the source has not been correctly analyzed will be reported.

C++ Source Checker provides a command line access. An integration is also available in C++ interactive dashboard. Command line usage is of the form:

mkCheckSource -f framework_to_analyze -html output_directory

Parse of C++ code can operate from the workspace to be analyzed and a provided pattern matching list of frameworks inside this workspace. Developers can also start the parse providing only a pattern matching list of sources to be analyzed [9].

Only predefined rules are coded in the tool. These rules are either native C++ coding rules, or CAA coding rules. No open API is available for user coding rules.

CSC tool works with XML setting files. Default setting files are provided. Users can define their own setting files and append these setting files to delivered ones or replace delivered setting files by their own setting files [10].

CSC provides a full HTML report with hyperlink to defaulter C++ source, ready to be exploited. It includes full features hyperlink that allow a deep analysis from framework to responsible C++ source line. Detected errors are highlighted at all level from framework to module to C++ source line and word. This ensures an easy and reliable analysis of the checked code that permits a fast correction.

[Top]


In Short

Different C++ rules are checked against the source code. Thanks to these checks, time spent to debug applications is drastically reduced, and quality of the code is improved. Developers are provided with a number of rules that help them reduce memory inherent bugs in domain such as application memory management, call back mechanism usage, exception handling and C++ programming rules. These sensitive checks ensure a better control of application quality and globally decrease the number of bugs related to memory corruption. Another aspect when checking sources is the ability to analyze discrepancies uses of C++ null pointers. This check ensures a better control on the number of core dump occurring during the execution of the application. The last aspect would be the detection of migration problems.

[Top]


References

[1] AddRef Release Checks
[2] Null Pointers Part 1 Checks
[3] Null Pointers Part 2 Checks
[4] Forbidden constructions Checks
[5] Callbacks Checks
[6] Exception Checks
[7] C++ Checks
[8] Inside the Parser
[9] Quick Ref
[10] Setting Files
[Top]

History

Version: 1 [Apr 2001] Document created
[Top]

Copyright © 2000, Dassault Systèmes. All rights reserved.