1. Configuring the Checker
- 1.1. Individual command line checking options
- 1.2. Customising checking profiles
- 1.3. Scoping checking profiles
- 1.4. Other checks
This section describes the built-in checking modes and the design of customised environments.
There are several methods available for configuring the checker. Most configuration is provided by built-in "modes" which are selected by using the relevant -X command line option for tcc. These modes are documented by tccmodes.
More detailed customisation may require special #pragma statements to be incorporated into the source code to be analysed (this commonly takes the form of a startup file). The configuration options generally act independently of one another and unless explicitly forbidden in the descriptions below, they may be combined in any way.
1.1. Individual command line checking options
Some of the checks available can be controlled using a command line option of the form -Xopt,opt,..., where the various opt options give a comma-separated list of commands. These commands have the form test=status, where test is the name of the check, and status is either check (apply check and give an error if it fails), warn (apply check and give a warning if it fails) or dont (do not apply check). The names of checks can be found with their descriptions in Chapters 3 - 8; for example the check for implicit function declarations described in 3.4.1 may be switched on using -X:implicit_func=check.
The command line options for portability checking are:
| Check | Reference | Command Line Option |
|---|---|---|
| Weak Prototype Analysis | 3.3.1 | -X:weak_proto=status |
| Implicit Function Declaration | 3.4 | -X:implicit_func=status |
| Printf String Checking | 3.2.2 | -X:printf=status |
| Incompatible Void Returns | 3.2.2 | -X:void_ret=status |
| Unreachable Code | 5.2 | -X:unreached=status |
| Case Fall Through | 5.3 | -X:fall_thru=status |
| Conversion Analysis | 3.2 | -X:convert_all=status |
| Integer ↔ Integer Conversion | 3.2.1 | -X:convert_int=status |
-X:convert_int_implicit=status | ||
-X:convert_int_explicit=status | ||
| Integer ↔ Pointer Conversion | 3.2.2 | -X:convert_int_ptr=status |
| Integer ↔ Pointer Conversion | 3.2.3 | -X:convert_ptr=status |
Complete struct/union Analysis | 8.3 | -X:complete_struct=status |
| Variable Analysis | 5.6 | -X:variable=status |
| Discard Analysis | 5.8 | -X:discard_all=status |
| Discarded Function Returns | 5.8.1 | -X:discard_func_ret=status |
| Discarded Values | 5.8.2 | -X:discard_value=status |
| Unused Statics | 5.8.3 | -X:unused_static=status |
where status can be check, warn or dont.
1.2. Customising checking profiles
The individual checks performed by the C static checker are generally controlled by #pragma directives. The reason for this is that the ISO standard places no restrictions on the syntax following a #pragma preprocessing directive, and most compilers/checkers can be configured to ignore any unknown #pragma directives they encounter.
Most of these directives begin:
#pragma TenDRA ...
and are always checked for syntactical correctness. The individual directives, together with the checks they control are described in Chapters 3 - 8. Section 2.2 describes the method of constructing a new checking profile from these individual checks.
1.3. Scoping checking profiles
Almost all the available checks are scoped (exceptions will be mentioned in the description of the check). Scopes may be controlled by the same #pragma TenDRA begin directive described by the C/C++ Producer Configuration Guide.
1.4. Other checks
Several checks of varying utility have been implemented in the C++ producer but do not as yet have individual directives controlling their use. These can be enabled en masse using the directive:
#pragma TenDRA++ catch all allow
It is intended that this directive will be phased out as these checks are assigned controlling directives. It is possible to achieve finer control over these checks by enabling their individual error messages as described above.