CWE Rule 571

This issue occurs when a block of code cannot be reached because of a condition that is always true or false. This defect excludes:

Dead code wastes development time, memory and execution cycles. Developers have to maintain code that is not being executed. Instructions that are not executed still have to be stored and cached.

Dead code often represents legacy code that is no longer used. Cleaning up dead code periodically reduces future maintenance.

The fix depends on the root cause of the defect. For instance, the root cause can be an error condition that is checked twice on the same execution path, making the second check redundant and the corresponding block dead code.

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 see dead code from use of functions such as isinf and isnan, enable an analysis mode that takes into account non-finite values. See Consider non finite floats (-allow-non-finite-floats).

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

#include <stdio.h>

int Return_From_Table(int ch){

    int table[5];

    /* Create a table */
    for(int i=0;i<=4;i++){
        table[i]=i^2+i+1;
    }

    if(table[ch]>100){ //Noncompliant
         return 0;  
    }
    return table[ch];
}

The maximum value in the array table is 4^2+4+1=21, so the test expression table[ch]>100 always evaluates to false. The return 0 in the if statement is not executed.

One possible correction is to remove the if condition from the code.

#include <stdio.h>

int Return_From_Table(int ch){

    int table[5];

    /* Create a table */
    for(int i=0;i<=4;i++){
        table[i]=i^2+i+1;
    }

    return table[ch];
}

typedef enum _suit {UNKNOWN_SUIT, SPADES, HEARTS, DIAMONDS, CLUBS} suit;
suit nextcard(void);
void do_something(suit s);

void bridge(void)
{
    suit card = nextcard();
    if ((card < SPADES) || (card > CLUBS))
        card = UNKNOWN_SUIT;

    if (card > 7) {  //Noncompliant
        do_something(card);
    }
}

The type suit is enumerated with five options. However, the conditional expression card > 7 always evaluates to false because card can be at most 5. The content in the if statement is not executed.

One possible correction is to change the if-condition in the code. In this correction, the 7 is changed to HEART to relate directly to the type of card.

typedef enum _suit {UNKNOWN_SUIT, SPADES, HEARTS, DIAMONDS, CLUBS} suit;
suit nextcard(void);
void do_something(suit s);

void bridge(void)
{
    suit card = nextcard();
    if ((card < SPADES) || (card > CLUBS))
        card = UNKNOWN_SUIT;

    if (card > HEARTS) {
        do_something(card);
    }
}

This issue occurs on if-statements where the condition is always true. This issue occurs only on if-statements that do not have an else-statement.

This defect shows unnecessary if-statements when there is no difference in code execution if the if-statement is removed.

Unnecessary if statements often indicate a coding error. Perhaps the if condition is coded incorrectly or the if statement is not required at all.

The fix depends on the root cause of the defect. For instance, the root cause can be an error condition that is checked twice on the same execution path, making the second check redundant.

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 the redundant condition represents defensive coding practices and you do not want to fix the issue, add comments to your result or code to avoid another review. See:

typedef enum _suit {UNKNOWN_SUIT, SPADES, HEARTS, DIAMONDS, CLUBS} suit;
suit nextcard(void);
void do_something(suit s);

void bridge(void)
{
    suit card = nextcard();
    if ((card < SPADES) || (card > CLUBS)){
        card = UNKNOWN_SUIT;
    }

    if (card < 7) {  //Noncompliant
        do_something(card);
    }
}

The type suit is enumerated with five options. However, the conditional expression card < 7 always evaluates to true because card can be at most 5. The if statement is unnecessary.

One possible correction is to change the if-condition in the code. In this correction, the 7 is changed to UNKNOWN_SUIT to relate directly to the type of card.

typedef enum _suit {UNKNOWN_SUIT, SPADES, HEARTS, DIAMONDS, CLUBS} suit;
suit nextcard(void);
void do_something(suit s);

void bridge(void)
{
    suit card = nextcard();
    if ((card < SPADES) || (card > CLUBS)){
        card = UNKNOWN_SUIT;
    }

    if (card > UNKNOWN_SUIT) {
        do_something(card);
    }
}

Another possible correction is to remove the if-condition in the code. Because the condition is always true, you can remove the condition to simplify your code.

typedef enum _suit {UNKNOWN_SUIT, SPADES, HEARTS, DIAMONDS, CLUBS} suit;
suit nextcard(void);
void do_something(suit s);

void bridge(void)
{
    suit card = nextcard();
    if ((card < SPADES) || (card > CLUBS)){
        card = UNKNOWN_SUIT;
    }

    do_something(card);
}