Check Why a Bug Finder Defect Does Not Appear as Expected

Issue

The default code analysis with Polyspace Bug Finder might not raise some potential defects. If an expected defect does not appear, you might need to enable additional checkers, and specify checkers options that are appropriate for your analysis. For instance:

void foo(int* p, int i) {
    *p = i; 
}

In this code example, the function foo dereferences a pointer with an unknown origination point. You might expect Bug Finder to flag the pointer as tainted. A default Bug Finder analysis does not look for tainted pointers. To flag pointers that originate outside the current analysis perimeter as tainted, enable the checker TAINTED_PTR. Then, limit your trust boundary by using the option -consider-analysis-perimeter-as-trust-boundary.

Possible Solutions

Check If Defect Checker Is Enabled

The default Bug Finder analysis enables a subset of the defect checkers. See Polyspace Bug Finder Defects Checkers Enabled by Default. To enable for other Bug Finder defects:

Polyspace^® desktop user interface: Select the checkers that you want to enable in the Bug Finder Analysis node of the Configuration pane.
Polyspace as You Code IDE plugins: Select the checkers that you want to enable in the Checkers Selection window. See Setting Checkers in Polyspace as You Code.
Command Line Interface: Open the Checkers Selection window by using the command polyspace-checkers-selection. Select the checkers that you want to enable, and then save your selection in an XML file. When running a Bug Finder analysis, use this file as the input to the command Checkers activation file (-checkers-activation-file). Instead of specifying a file, you can also enumerate the checkers explicitly or use a predefined subset using the option Find defects (-checkers).

When checking for specific issues, the best practice is to enable specific checkers corresponding to the issues.

Check If Defect Checker Needs to Be Extended

Some constructs in your code might cause issues in some specific contexts. A default Bug Finder analysis might not flag these potential defects to reduce false positives. Detect these issues by extending the existing Bug Finder defect checkers. Modify the checker behavior by using these options:

-consider-analysis-perimeter-as-trust-boundary: By default, Polyspace considers only the user inputs as tainted. By using this option, you consider any data that originates outside the current analysis perimeter as tainted. See Sources of Tainting in a Polyspace Analysis.
-detect-atomic-data-race: By default, Polyspace assumes that certain operations are atomic and excludes them from data race checks. These operations might not be atomic in your environment. Use this option to extend the data race checkers to include the assumed atomic operations. See Extend Data Race Checkers to Atomic Operations.

For a complete list of options that extend or modify Bug Finder checkers, see Modify Checker Behavior.

Check If Analysis Needs Additional Information on Code

Some checkers might require additional information about your code in order to detect certain defects. For instance:

Standard library math function checkers. By default, these checkers check for invalid use of standard library math functions. If you use a custom math library with domain or other constraints, a default Polyspace analysis cannot detect the violation of those constraints. If your custom library functions have similar domains and constraints to standard library math functions, you can extend these checkers to your custom library. See Extend Bug Finder Checkers for Standard Library Functions to Custom Libraries.
Concurrency checkers. By default, Polyspace Bug Finder automatically detects thread creation and protection mechanisms if you use routines from certain libraries. See Auto-Detection of Thread Creation and Critical Section in Polyspace. If you use a custom concurrency library that Polyspace does not support, to detect potential defects, do either of these:
- If possible, map the custom library to a supported library See Extend Concurrency Defect Checkers to Unsupported Multithreading Environments.
- Configure the analysis manually. See Configuring Polyspace Multitasking Analysis Manually.
Checkers that check for blocklisted keywords and functions. These checkers cannot flag the blocklisted keywords and functions unless you specify which ones are blocklisted. See Flag Deprecated or Unsafe Functions, Keywords, or Macros Using Bug Finder Checkers.

For a complete list of checkers that need additional information about your code, see Modify Polyspace Interpretation of Code.

Check Bug Finder Assumptions

To minimize results that can be perceived as false positives, Bug Finder makes certain assumptions when running a Bug Finder analysis. For instance:

By default, Polyspace does not raise a defect that is caused by a specific value of an unknown input. See Inputs in Polyspace Bug Finder.
Polyspace ignores the initialization value of local volatile variables. The initialization value of global volatile objects depend on their const-ness and their Init Mode. See Volatile Variables in Polyspace Bug Finder.

For a list of these assumptions, see Bug Finder Analysis Assumptions.

These assumptions might prevent Bug Finder from detecting some potential defects. In these cases, run Code Prover for a more exhaustive analysis. For instance, consider this code:

int foo(void){
    volatile var=0;
    return 1/var; // Potential defect
}

The statement return 1/var is a potential divide-by-zero error. Because of Bug Finder assumptions, this defect is not detected. A Code Prover analysis flags this issue as an orange check.

Check If Defect is in Unused Code

If your code has uninstantiated class template, a Polyspace Bug Finder™ defect might not be reported on the class. The objects in standard template library (STL) are class templates. If you do not see an expected defect on an STL class, instantiate an object of the class.
If your code contains unused typedef and function declarations, these Polyspace Bug Finder defects might not be reported:

Check If Defect Is in Uncalled `static` Function

If finding a defect requires keeping track of data propagation between functions, the defect is called an inter-procedural defect. Bug Finder does not check the following kinds of functions for intra-procedural defects:

static functions that are not called directly or indirectly from main() or another non-static function.
Functions that are called only from the above static functions.

To find inter-procedural defects in a static function, call the static function in your code.