CWE Rule 617

This issue occurs when you use an assert, and the asserted expression is or could be false.

Typically you use assert statements for functional testing in debug mode. An assertion failure found using static analysis indicates that the corresponding functional test would fail at run time.

The fix depends on the root cause of the defect. For instance, the root cause can be unconstrained input from an external source that eventually led to the assertion failure.

Often the result details (or source code tooltips in Polyspace as You Code) show a sequence of events that led to the defect. You can implement the fix on any event in the sequence. If the result details do not show this event history, you can search for previous references of variables relevant to the defect using right-click options in the source code and find related events. See also Interpret Bug Finder Results in Polyspace Desktop User Interface or Interpret Bug Finder Results in Polyspace Access Web Interface (Polyspace Access).

See examples of fixes below.

If you do not want to fix the issue, add comments to your result or code to avoid another review. See:

A default Bug Finder analysis might not raise this defect when the input values are unknown and only a subset of inputs cause an issue. To check for defects caused by specific system input values, run a stricter Bug Finder analysis. See Extend Bug Finder Checkers to Find Defects from Specific System Input Values.

#include <assert.h>

void asserting_x(unsigned int theta) {
    theta =+ 5;
    assert(theta < 0);  //Noncompliant
}

In this example, the assert function checks if the input variable, theta, is less than or equal to zero. The assertion fails because theta is an unsigned integer, so the value at the beginning of the function is at least zero. The += statement increases this positive value by five. Therefore, the range of theta is [5..MAX_INT]. theta is always greater than zero.

One possible correction is to change the assertion expression. By changing the less-than-or-equal-to sign to a greater-than-or-equal-to sign, the assertion does not fail.

#include <assert.h>

void asserting_x(unsigned int theta) {
    theta =+ 5;
    assert(theta > 0);
}

One possible correction is to fix the code related to the assertion expression. If the assertion expression is true, fix your code so the assertion passes.

#include <assert.h>
#include <stdlib.h>

void asserting_x(int theta) {
    theta = -abs(theta);
    assert(theta < 0);
}

#include <assert.h>

#define FLAG 0

int main(void){
    int i_test_z = 0;
    float f_test_z = (float)i_test_z;

    assert(i_test_z);  //Noncompliant
    assert(f_test_z);  //Noncompliant
    assert(FLAG);

    return 0;
}

In this example, Polyspace does not flag assert(FLAG) as a violation because a macro defines FLAG as 0. The Polyspace Bug Finder™ assertion checker does not flag assertions with a constant zero parameter, assert(0). These types of assertions are commonly used as dynamic checks during runtime. By inserting assert(0), you indicate that the program must not reach this statement during run time, otherwise the program crashes.

However, the assertion checker does flag failed assertions caused by a variable value equal to zero, as seen in the example with assert(i_test_z) and assert(f_test_z).