Main Content

CWE Rule 561

Dead Code

Since R2023a

Description

Rule Description

The software contains dead code, which can never be executed.

Polyspace Implementation

The rule checker checks for these issues:

  • Dead code

  • Static uncalled function

  • Unreachable code

Examples

expand all

Issue

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

Risk

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.

Fix

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:

Example — Dead Code from if-Statement
#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.

Correction — Remove Dead Code

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];
}
Example — Dead Code for if with Enumerated Type
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.

Correction — Change Condition

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);
    }
}
Issue

This issue occurs when a static function is not called in the same file where it is defined.

Risk

Uncalled functions often result from legacy code and cause unnecessary maintenance.

Fix

If the function is not meant to be called, remove the function. If the function is meant for debugging purposes only, wrap the function definition in a debug macro.

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:

Example — Uncalled function error

Save the following code in the file Initialize_Value.c

#include <stdlib.h>
#include <stdio.h>

static int Initialize(void) //Noncompliant
/* Defect: Function not called */
  {
   int input;
   printf("Enter an integer:");
   scanf("%d",&input);
   return(input);
  }
  
 void main()
  {
   int num;

   num=0;

   printf("The value of num is %d",num);
  }

The static function Initialize is not called in the file Initialize_Value.c.

Correction — Call Function at Least Once

One possible correction is to call Initialize at least once in the file Initialize_Value.c.

#include <stdlib.h>
#include <stdio.h>

static int Initialize(void)
  {
   int input;
   printf("Enter an integer:");
   scanf("%d",&input);
   return(input);
  }

 void main()
  {
   int num;

   /* Fix: Call static function Initialize */
   num=Initialize();
    
   printf("The value of num is %d",num);
  }
Issue

This issue occurs when a section of code cannot be reached because of a previous break in control flow.

Statements such as break, goto, and return, move the flow of the program to another section or function. Because of this flow escape, the statements following the control-flow code, statistically, do not execute, and therefore the statements are unreachable.

This check also finds code following trivial infinite loops, such as while(1). These types of loops only release the flow of the program by exiting the program. This type of exit causes code after the infinite loop to be unreachable.

Risk

Unreachable 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.

Fix

The fix depends on the intended functionality of the unreachable code. If you want the code to be executed, check the placement of the code or the prior statement that diverts the control flow. For instance, if the unreachable code follows a return statement, you might have to switch their order or remove the return statement altogether.

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

Example — Unreachable Code After Return
typedef enum _suit {UNKNOWN_SUIT, SPADES, HEARTS, DIAMONDS, CLUBS} suit;
suit nextcard(void);
void guess(suit s);

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

    if (card < HEARTS) { //Noncompliant
        guess(card);
    }
    return card;
}

In this example, there are missing braces and misleading indentation. The first return statement changes the flow of code back to where the function was called. Because of this return statement, the if-block and second return statement do not execute.

If you correct the indentation and the braces, the error becomes clearer.

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

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

    if (card < HEARTS) {  //Noncompliant
        guess(card);
    }
    return card;
}

Correction — Remove Return

One possible correction is to remove the escape statement. In this example, remove the first return statement to reach the final if statement.

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

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

    if(card < HEARTS)
    {
        guess(card);
    }
    return card;
}
Correction — Remove Unreachable Code

Another possible correction is to remove the unreachable code if you do not need it. Because the function does not reach the second if-statement, removing it simplifies the code and does not change the program behavior.

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

suit deal(void){
    suit card = nextcard();
    if( (card < SPADES) || (card > CLUBS) )
    {
        card = UNKNOWN_SUIT;
    }
    return card;
}
Example — Infinite Loop Causing Unreachable Code
int add_apples(int apple) { 
    int count = 1;
    while(1) {
        if(apple < 99){
            apple++; 
            count++;
        }else{
            count--;
        }
    }
    return count;  //Noncompliant
}

In this example, the while(1) statement creates an infinite loop. The return count statement following this infinite loop is unreachable because the only way to exit this infinite loop is to exit the program.

Correction — Rewrite Loop Condition

One possible correction is to change the loop condition to make the while loop finite. In the example correction here, the loop uses the statement from the if condition: apple < 99.

int add_apples1(int apple) { 
    int count = 0;
    while(apple < 99) { 
        apple++; 
        count++;
    }
    if(count == 0)
        count = -1;
    return count;
}
Correction — Add a Break Statement

Another possible correction is to add a break from the infinite loop, so there is a possibility of reaching code after the infinite loop. In this example, a break is added to the else block making the return count statement reachable.

int add_apples(int apple) { 
    int count = 1;
    while(1) {
        if(apple < 99)
        {
            apple++; 
            count++;
        }else{
            count--;
            break;
        }
    }
    return count;
}
Correction — Remove Unreachable Code

Another possible correction is to remove the unreachable code. This correction cleans up the code and makes it easier to review and maintain. In this example, remove the return statement and change the function return type to void.

void add_apples(int apple) { 
    int count = 1;
    while(1) {
        if(apple < 99)
        {
            apple++; 
            count++;
        }else{
            count--;
        }
    }
}

Check Information

Category: Bad Coding Practices

Version History

Introduced in R2023a