Modify Default Behavior of Bug Finder Checkers

A Polyspace^® Bug Finder™ analysis checks C/C++ code for bugs and external coding standard violations. By default, the Bug Finder checkers are designed to:

Show as few false positives as possible.
Require minimal setup upfront.

However, for specific projects, you might want to modify the default behavior of some checkers. For instance, you might want to treat some user defined data types as effectively boolean or detect data races involving operations that Bug Finder considers as atomic by default.

Use this topic to find the modifications allowed for Bug Finder checkers. Alternatively, you can search for these options in the analysis report to see if the default behavior of checkers were modified.

Note that:

The options do not enable or disable a checker.
To enable or disable specific checkers, see Choose Specific Bug Finder Defect Checkers.
You can use these options solely to modify the behavior of an existing checker.
Options such as target processor type, multitasking options and external constraints can also modify the behavior of a checker. However, the modification happens as a side effect. You typically specify these options to accurately reflect your target environment.

Defect Checkers and Coding Rules Modified by Analysis Options

When using Bug Finder, use the analysis option in two different ways. You can:

Modify how a checker behaves.
Modify how Polyspace interprets the code behavior.

Modify Checker Behavior

Use the following options to change the default behavior of Bug Finder defects and coding rule checkers. For instance, use -checks-using-system-input-values to run a stricter check.

Option	Option Value	Checkers Modified	Modification
`Run stricter checks considering all values of system inputs (-checks-using-system-input-values)`		Checkers and coding rules that rely on numerical values of system inputs. See Checkers That Can Be Extended.	See Extend Bug Finder Checkers to Find Defects from Specific System Input Values.
`-consider-analysis-perimeter-as-trust-boundary`		Tainted Data Defects and related coding rule violations. See Polyspace Tainted Data Checkers.	By default, the tainted data defects consider externally obtained data as tainted. By using this option, the following are also considered as tainted data: Formal parameters of externally visible function that do not have a visible caller. Return values of stubbed functions. Global variables external to the unit. See Sources of Tainting in a Polyspace Analysis
`Check guidelines (-guidelines)`	XML file. Entries in the XML file define the thresholds for software complexity checkers	Software Complexity Guidelines	See Reduce Software Complexity by Using Polyspace Checkers
`-detect-atomic-data-race`		`CERT C: Rule CON43-C` `CERT C++: CON43-C` `Data race` `CWE Rule 366` `CWE Rule 413`	By default, these checkers flags data races involving non-atomic operations. If an operation is atomic, it cannot be interrupted by operations in another task or thread. If you use this option, all operations are considered when flagging data races. See also Extend Data Race Checkers to Atomic Operations.
`-detect-bad-float-op-on-zero`		`Floating point comparison with equality operators` `CERT C: Rec. FLP02-C`	By default, the checker ignores floating point comparisons with equality operators if one of the operands is 0.0. If you use this option, comparisons with 0.0 are also flagged.

Modify Polyspace Interpretation of Code

Use these options to modify how Polyspace interprets the code. For instance, use -boolean-types to indicate that certain data types in your code are effectively Boolean or use the option -code-behavior-specification to specify certain behaviors of your code.

Option	Option Value	Checkers Modified	Modification
`Effective boolean types (-boolean-types)`	Data types	MISRA C™:2004 rules 12.6, 13.2, 15.4 MISRA C:2012 rules 10.1, 10.3, 10.5, 14.4, 16.7 `MISRA C++:2008 Rule 6-4-7` and `AUTOSAR C++14 Rule M6-4-7` JSF AV C++ coding rule 195	The rules covered by these checkers involve boolean types. If you use this option, you can treat user-defined types as effectively boolean.
`Consider non finite floats (-allow-non-finite-floats)`		Checkers and coding rules related to float numerical operations. See `Consider non finite floats (-allow-non-finite-floats)`.	If you use this option, Polyspace incorporates infinities and NaNs in floating point checks. Checkers that flag infinities and NaNs in floating point operations might be disabled or flag less defects.
`Allowed pragmas (-allowed-pragmas)`	Names of pragmas	MISRA C:2004 rule 3.4 and MISRA C++ rule 16-6-1	These rules require that all pragma directives must be documented within the compiler documentation. If you use this option, the analysis considers the pragmas specified as documented pragmas.
`-code-behavior-specifications`	XML file. Entries in the XML file map user-defined functions to functions from the Standard Library.	Checkers and coding rules that detect issues with Standard Library functions. See Checkers That Can Be Extended.	See Extend Bug Finder Checkers for Standard Library Functions to Custom Libraries.
	XML file. Entries in the XML file map user-defined concurrency primitives to ones that Bug Finder can automatically detect.	Concurrency defects and related coding rules. See Checkers That Can Be Extended.	See Extend Concurrency Defect Checkers to Unsupported Multithreading Environments.
	XML file. Entries in the XML file list functions, keywords or macros that you want to prohibit from your source code.	See Checkers That Can Be Extended.	See Flag Deprecated or Unsafe Functions, Keywords, or Macros Using Bug Finder Checkers.
	XML file. Entries in the XML file list functions whose pointer arguments must point to initialized buffers.	See Checkers That Can Be Extended	See Extend Checkers for Initialization to Check Function Arguments Passed by Pointers.
	XML file. Entries in the XML file define limits on global aspects of your program such as maximum depth of nesting in control flow statements.	MISRA C: 2012 Rule 1.1	You can increase or decrease these parameters of the rule checker: Maximum depth of nesting allowed in control flow statements Maximum levels of inclusion allowed using include files Maximum number of constants allowed in an enumeration Maximum number of macros allowed in a translation unit Maximum number of members allowed in a structure Maximum levels of nesting allowed in a structure See Modify Bug Finder Checkers Through Code Behavior Specifications.
	XML file. Entries in the XML file define how many characters are compared before considering two identifiers as distinct.	`MISRA C:2012 Rule 5.1` `MISRA C:2012 Rule 5.2` `MISRA C:2012 Rule 5.3` `MISRA C:2012 Rule 5.4` `MISRA C:2012 Rule 5.5` `CERT C: Rec. DCL23-C` `ISO/IEC TS 17961 [funcdecl]`	These rules require uniqueness of certain types of identifiers. For instance, rule 5.1 requires that external identifiers be distinct. If the difference between two identifiers occurs beyond the first `num` characters, the rule checker considers the identifiers as identical. You can modify the parameter `num` separately for external and internal identifiers. See Modify Bug Finder Checkers Through Code Behavior Specifications.
	XML file. Entries in the XML file defines functions as real-time functions and functions that manages dynamic memory.	`AUTOSAR C++14 Rule A18-5-7`	This rule requires that dynamic memory allocation and deallocation does not occur in real time. Polyspace assumes that no function in your code runs at real-time, and only certain standard library functions manages dynamic memory. Specify a function in your code as a real-time function by using the behavior `REAL_TIME_FUNC`. Specify a function in your code as a function that allocates or deallocates dynamic memory by using the behavior `MANAGES_MEMORY`. See Modify Bug Finder Checkers Through Code Behavior Specifications.
	XML file. Entries in the XML file defines functions that handle exceptions or manage dynamic memory.	`AUTOSAR C++14 Rule A15-0-7`	This rule requires that exception handling functions must have a deterministic worst-case execution time. Polyspace recognizes the commonly used exception handling functions and dynamic memory management functions. Specify a function in your code as a function that allocates or deallocates dynamic memory by using the behavior `MANAGES_MEMORY`. Specify a function in your code as a function that handles exceptions by using the behavior `EXCEPTION_HANDLING`. See Modify Bug Finder Checkers Through Code Behavior Specifications.
	XML file. Entries in the XML file defines critical data members.	`Critical data member is not private` `CWE Rule 493` `CWE Rule 498` `CWE Rule 766`	This checker flags the critical data members that are declared `public`. By default, Polyspace assumes that no data member is critical. Specify the critical data members in your code by using the behavior `CRITICAL_DATA`. See Modify Bug Finder Checkers Through Code Behavior Specifications.
	Datalog file. Entries in the datalog file define functions relevant to SQL or LDAP injection checkers.	`SQL injection` and `LDAP injection`	Specify custom functions that are sensitive to SQL or LDAP injection, functions that sanitize SQL or LDAP queries, and so on. See Modify Bug Finder Checkers Through Code Behavior Specifications.