A commonly used option for checking for Abstract Interpretation and Security violations are the Parasoft xTest tools.
The timeout in seconds can optionally be configured as a configuration property either on SERVER or PROJECT level. If this property is not configured in the SERVER or PROJECTS.txt, the TICS default value of 12 hours is used. The example sets the timeout for CppTest to 3600 seconds, Dottest to 1800 seconds, and Jtest to 7200 seconds. Note the capitalization; this is to match the internals of TICS.
'TOOLS' => { 'CppTest' => { 'TIMEOUT' => 3600, }, 'Dottest' => { 'TIMEOUT' => 1800, }, 'Jtest' => { 'TIMEOUT' => 7200, }, }
Note as well that this timeout is specified for a _single invocation_ of the tool. In the case that the tool works on the solution level (Dottest) or per buildfile (Jtest), then each invocation of these tools will get the specified timeout. For instance, in the case of a C# project, you may have multiple solution files contained in the project. Dottest is run once per solution file, since it analyzes everything in its solution context. Therefore, configuring a timeout for Dottest will mean that this timeout holds for each one of these runs on a single solution file.
cpptest.properties
dottest.properties
jtest.properties
Parameterization of a rule can be done as follows in the .properties file. For instance, this block will run the checker BD-API-BADPARAM with the options reportUnvalidatedViolations and aggressiveMode:
BD-API-BADPARAM=true BD-API-BADPARAM-reportUnvalidatedViolations=true BD-API-BADPARAM-aggressiveMode=true
The same can also be done via the TICS internal mechanism of the IMPL.txt file. To do parameterization in the IMPL.txt file, the following rules are used:
=
separates the implementation ID from parameters
;
separates different parameters
:
separates the parameter from its value
In practice, this looks like the following (for the same example as in the previous case):
BD-API-BADPARAM CppTest BD-API-BADPARAM=reportUnvalidatedViolations:true;aggressiveMode:true