Page History

...

int func(int condition) {
    char *s = NULL;
    if (condition) {
        s = (char *)malloc(10);
        if (s == NULL) {
           /* Handle Error */
        }
        /* Process s */
        return 0;
    }
    /* ...Code that doesn't touch s */
    if (s) {
        /* This code is unreachable */
    }
    return 0;
}

...

int func(int condition) {
    char *s = NULL;
    if (condition) {
        s = (char *)malloc(10);
        if (s == NULL) {
           /* Handle error */
        }
        /* Process s */
    }
    /* ... Code that doesn't touch s */
    if (s) {
        /* This code is now reachable */
    }
    return 0;
}

...

int s_loop(char *s) {
    size_t i;
    size_t len = strlen(s);
    for (i=0; i < len; i++) {
        /* ...Code that doesn't change s, i, or len */
	  if (s[i] == '\0') {
	    /* This code is never reached */
      }
    }
    return 0;
}

...

int s_loop(char *s) {
    size_t i;
    size_t len = strlen(s);
    for (i=0; i < len; i++) {
        /* ... */
	  Code that doesn't change s, i, or len */
	  if (s[i+1] == '\0') {
	    /* This code is now reached */
      }
    }
    return 0;
}

...

int *p;
/* ... */
(*p)++;

...

Another possibility is that p is being used to reference a memory-mapped device. In this case, the variable p should be declared as volatile.

...

if (param == 1)
   openWindow();
 else if (param == 2)
   closeWindow();
 else if (param == 1) /* Duplicated condition */
   moveWindowToTheBackground();

Note that duplicating a condition violates this guideline only if the duplicate conditions always behave similarly...see a compliant solution below for a condition that is textually a duplicate but behaves differently.

Compliant Solution (if/else if)

...

if (param == 1)
   openWindow();
 else if (param == 2)
   closeWindow();
 else if (param == 3)
   moveWindowToTheBackground();

Noncompliant Code Example (logical operators)

Compliant Solution (Conditional Side-Effects)

This code does not violate this recommendation, because even though the conditions are textually identical, they have different side effects, because the getc()  function advances the stream marker.Using the same subexpression on either side of a logical operator is almost always a mistake.  In this noncompliant code example, the rightmost subexpression of the controlling expression of each if statement has no effect.  

if (agetc() == b && a == b) { // if the first one is true, the second one is too
  do_x();
}
if (a == c || a == c ) { // if the first one is true, the second one is too
  do_w();
}

Compliant Solution (logical operators)

':')
   readMoreInput();
 else if (getc() == ':')
   readMoreInput();
 else if (getc() == ':')
   readMoreInput();

Noncompliant Code Example (logical operators)

Using the same subexpression on either side of a logical operator is almost always a mistake.  In this noncompliant code exampleIn this compliant solution, the rightmost subexpression of the controlling expression of each if statement has been removedno effect.  

if (a == b && a == b) { // if the first one is true, the second one is too
  do_x();
}
if (a == c || a == c ) { // if 
the  do_w(first one is true, the second one is too
  do_w();
}

Noncompliant Code Example (Unconditional Jump)

Compliant Solution (logical operators)

In this compliant solution, the rightmost subexpression of the controlling expression of each if statement has been removed.Unconditional jump statements typically has no effect.  

#include <stdio.h>
 
for (int i = 0; i < 10; ++iif (a == b) { 
  printf("i is %d", ido_x();
}
if (a continue;== c) //{ this
 is meaningless; the loop would continue anywaydo_w();
}

...

Noncompliant Code Example (Unconditional Jump)

The continue statement has been removed from this compliant solution.Unconditional jump statements typically has no effect.  

#include <stdio.h>
 
for (int i = 0; i < 10; ++i) {
   printf("i is %d", i); 
}

Exceptions

  continue;  // this is meaningless; the loop would continue anyway
}

Compliant Solution (Unconditional Jump)

The continue statement has been removed from this compliant solution. AnchorMSC07-EX1MSC07-EX1MSC07-C-EX1: In some situations, seemingly dead code may make software resilient. An example is the default label in a switch statement whose controlling expression has an enumerated type and that specifies labels for all enumerations of the type. (See MSC01-C. Strive for logical completeness.) Because valid values of an enumerated type include all those of its underlying integer type, unless enumeration constants are provided for all those values, the default label is appropriate and necessary.

typedef enum { Red, Green, Blue } Color;
const char* f(Color c#include <stdio.h>
 
for (int i = 0; i < 10; ++i) {
  switch printf(c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
    default: return "Unknown color";   /* Not dead code */
  }
}

void g() {
  Color unknown = (Color)123;
  puts(f(unknown));
}

...

"i is %d", i); 
}

Exceptions

typedef enum { Red, Green, Blue } Color;
const char* f(Color c) {
  switch (c) {
    case Red: return "Red";
    case Green: return "Green";
    case Blue: return "Blue";
    default: return "Unknown color";   /* Not dead code */
  }
}

void g() {
  Color unknown = (Color)123;
  puts(f(unknown));
}

Risk Assessment

The presence of code that has no effect or is never executed can indicate logic errors that may result in unexpected behavior and vulnerabilities. Such code can be introduced into programs in a variety of ways and eliminating it can require significant analysis.

Automated Detection

Risk Assessment

The presence of code that has no effect or is never executed can indicate logic errors that may result in unexpected behavior and vulnerabilities. Such code can be introduced into programs in a variety of ways and eliminating it can require significant analysis.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

CVE-2014-1266 results from a violation of this rule. There is a spurious goto fail statement on line 631 of sslKeyExchange.c. This goto statement gets executed unconditionally, even though it is indented as if it were part of the preceding if statement. As a result, the call to sslRawVerify() (which would perform the actual signature verification) becomes dead code [ImperialViolet 2014].

Related Guidelines

Bibliography

...

[Fortify 2006]	Code Quality, "Dead Code"
[Coverity 2007]

 

 

 

...

Image Modified Image Modified Image Modified