RADE

C++ Source Checker

mkCheckSource Setting Files

Testing source code in the CAA V5 environment
Technical Article

Abstract

Setting Files are the way external settings (like lists of methods, ...) are given to the tool.

What is a Setting File ?

Presentation of Setting Files

Setting files are used to give CSC external information about the source code (which methods return an AddRef'ed pointer, which classes are "non-deletable" ...) and to configure the run (which type of run to do, which errors to check, which frameworks to ignore ...).

Default setting files are delivered, and used by default by the tool. The user can :

Setting Files are written in XML. The default setting file is provided, plus its DTD (Document Type Definition) (Settings_ClientCheck.xml and CheckSourceSettings.dtd files, in Runtime View / resources / mkCheckSource). This file can be created or modified by any XML editor (Microsoft XML Notepad, for example).

Provided Setting File

One default setting files is provided, Settings_ClientCheck.xml, defining a run to detect coding errors, for both code and test frameworks. Detection is made against the most important rules.

[Top]

Creating or modifying a setting file

If you want to add new user inputs to the tool, you can either modify a delivered setting file, or write your own setting file from scratch. Copying a delivered setting file to modify it is faster and easier than writing a setting file from scratch. An XML file can be modified either in a text editor or in an XML editor. If you don't have any notion of XML, please refer to a specific documentation.

As soon as you get your new setting file, use the DTD to check if your modifications are valid. You can, for example, open the new setting file with an XML editor checking the DTD (like XML notepad, or most of the existing XML editors...). If your file is not valid according to the DTD, an error will be reported by the editor. If it is valid, you can use it to run CSC.

[Top]

Using your own Setting File

When you have written a setting file, you can overload a delivered setting file with your own setting file, or use only your setting file. The different command lines are described in [1] (Using your own Setting File, Using several Setting Files).

[Top]

Structure of a Setting File

To get the exact and exhaustive structure of setting files, see the provided DTD.

Every setting file has a root node named SettingsSet. This root node contains a the most 3 sections (three child nodes) : RunType, ReportSet and OptionLists.

 

RunType

This section consists in 3 blocks:

 

ReportSet

This section defines the list of activated errors. It contains a list of Report, each Report containing the name of an error and the state of this error : Activate = true means that this error will be reported, Activate = false means that this error will not be reported.

If you want to ignore some errors, you can write your own setting file to de-activate these errors (Activate= false) and overload the default setting file with your own setting file: the errors de-activated in your setting file will not be checked.

 

OptionLists

This section defines, for every category of checks, the user inputs. For more information, refer to the article describing the check :

 

Global_OptionLists

This section defines options common to all the checks. 

For the moment, the only section is Macro2Expand, which contains all the macros to be expanded by CSC. Macro expansion is described in [8].

 

[Top]

In Short

 

[Top]

References

[1] Quick Ref
[2] Null Pointers Part 1 Checks
[3] Null Pointers Part 2 Checks
[4] AddRef Release Checks
[5] Exception Checks
[6] Forbidden Constructions Checks
[7] C++ Checks
[8] Inside the Parser
[Top]

History

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

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