Diagnose Why Coding Standard Violations Do Not Appear as Expected

Issue

You expect a coding rule violation on a line of code but the Polyspace^® Bug Finder™ analysis does not show the violation.

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 Rule Checker Is Enabled

You might have enabled a reduced subset of coding rules that exclude the expected rule.

For instance, if you check for MISRA C™: 2012 rules, the analysis enables only the mandatory-required subset by default. To check for other MISRA C: 2012 rules, specify the appropriate option.

Review the coding rules options that you use. See Coding Standards and Code Metrics.

Check If Source File Is Excluded from Analysis

By default, coding rule violations are suppressed from header files that are not in the same location as the source files. Some source files might be excluded from the coding rule analysis intentionally. See Do not generate results for (-do-not-generate-results-for). If you are analyzing such a file, all coding rule violations in the file might be suppressed.

Check If Rule Violation Is in Macros

When a rule violation occurs in a macro definition, Polyspace shows the result only once in the macro definition. A violation is reported on an instance of a macro only when the rule violation occurs explicitly because of the parameters of the macro instance. If the macro definition occurs in a header file, it might be suppressed from the results. See also Polyspace Results in Lines Containing Macros. If you expect a coding rule violation on a macro:

Check the macro definition for the violation.
If the macro definition is in a header file, check if you are suppressing coding rule violations from header files. See Do not generate results for (-do-not-generate-results-for).

On the Source pane, to see if a line contains a macro expansion, look for the icon.

Check for Compilation Errors

If any source file in the analysis does not compile, coding rules checking remains incomplete. The coding rules checker results:

Might not contain full results for files that did not compile.
Might not contain full results for the files that did compile because some rules are checked only after compilation is complete.

Check for compilation errors. See View Error Information When Polyspace Analysis Stops.

Check If Rule Checker Needs to Be Extended

Some constructs in your code might violate a coding rule in some specific contexts. A default Bug Finder analysis might not report these potential violations to reduce false positives. Detect these issues by extending the existing Bug Finder coding rule 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 list of options that extend or modify Bug Finder checkers, see Modify Default Behavior of Bug Finder Checkers.

Check If Analysis Needs Additional Information on Code

Polyspace might require additional information about your code to detect certain coding rule violations. For instance:

Rule checkers related to the correct use of standard library math function — 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.
Rule checkers related to multitasking issues — 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.
Rule checkers related to the use of 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.
Rule checker related to use of dynamic memory and real time functions — These checkers cannot flag use of dynamic memory or other violations in real time functions unless you specify which functions are realtime and which functions allocate dynamic memory. See Modify Bug Finder Checkers Through Code Behavior Specifications.

For a complete list of checkers that need additional information about your code, see Modify Default Behavior of Bug Finder Checkers.

Check If Rule Applies to Source Files

Some coding rules apply only to header files. Violations of these rules are not reported in nonheader source files. For instance, violations of rules such as MISRA C++:2008 Rule 3-1-1 or AUTOSAR C++14 Rule A3-1-1 are reported only in header files.

Check If Rule Violation Is in Uncalled `static` Function

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

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 detect inter-procedural coding rule violations in a static function, call the static function in your code.

Check If Violation Is in Unused Code

Bug Finder does not report coding rule violations on certain code constructs if they are unused. For instance:

Templates and Macros: Some coding rule violations are not reported on uninstantiated templates and unused macros.
Function declarations and typedefs: Violations of coding rules that check for mismatches in declarations and typedefs might not be reported on unused function declarations and typedefs.

To check these code constructs for all possible coding rule violations, invoke them at least once in your code.

Check If Required Multitasking Options are Specified

For multitasking related rule checkers, might need to specify concurrency options to see violations of these rules.

Polyspace detects some multitasking libraries automatically. See Auto-Detection of Thread Creation and Critical Section in Polyspace. Depending on your library, you might need to configure the multitasking options manually. See Configuring Polyspace Multitasking Analysis Manually. You can also map your library to a supported library using the option -code-behavior-specifications. See Extend Concurrency Defect Checkers to Unsupported Multithreading Environments.

Check If MISRA C Coding Rule Violation is in Conditional Preprocessor Block

Code within conditional preprocessor blocks such as #if or #ifdef are excluded from the preprocessed code if the condition is false. The MISRA C coding rules apply to the code that remains after preprocessing. Rule violations in conditional preprocessor blocks are not reported when the condition is false. For example, consider this code:

#ifdef MACRO_ACTIVATION_1

typedef unsigned char activation_by_macro_uchar; //Unused type 

#endif

The code within the #ifdef block is absent in the preprocessed code if the macro MACRO_ACTIVATION_1 is not defined. MISRA C coding rule violations in this line are not reported in that case.