Skip to end of metadata
Go to start of metadata

Deprecated

This rule has been deprecated.  It has been merged with:

10/07/2014 -- Version 2.0


Code that is never executed is known as dead code. Typically, the presence of dead code indicates that a logic error has occurred as a result of changes to a program or the program's environment. Dead code is usually optimized out of a program during compilation. However, to improve readability and ensure that logic errors are resolved, dead code should be identified, understood, and eliminated.

This recommendation is related to MSC12-C. Detect and remove code that has no effect or is never executed.

Noncompliant Code Example

This noncompliant code example demonstrates how dead code can be introduced into a program [Fortify 2006]. The second conditional statement, if (s), will never evaluate true because it requires that s not be assigned NULL, and the only path where s can be assigned a non-null value ends with a return statement.

int func(int condition) {
    char *s = NULL;
    if (condition) {
        s = (char *)malloc(10);
        if (s == NULL) {
           /* Handle Error */
        }
        /* Process s */
        return 0;
    }
    /* ... */
    if (s) {
        /* This code is never reached */
    }
    return 0;
}

Compliant Solution

Remediation of dead code requires the programmer to determine why the code is never executed and then to resolve the situation appropriately. To correct the preceding noncompliant code, the return is removed from the body of the first conditional statement.

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

Noncompliant Code Example

In this example, the strlen() function is used to limit the number of times the function s_loop() will iterate. The conditional statement inside the loop evaluates to true when the current character in the string is the null terminator. However, because strlen() returns the number of characters that precede the null terminator, the conditional statement never evaluates true.

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

Compliant Solution

Removing the dead code depends on the intent of the programmer. Assuming the intent is to flag and process the last character before the null terminator, the conditional is adjusted to correctly determine if the i refers to the index of the last character before the null terminator.

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

Exceptions

MSC07-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) {
  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));
}

MSC07-EX2: It is also permissible to temporarily remove code that may be needed later. (See MSC04-C. Use comments consistently and in a readable fashion for an illustration.)

Risk Assessment

The presence of dead code may indicate logic errors that can lead to unintended program behavior. The ways in which dead code can be introduced into a program and the effort required to remove it can be complex. As a result, resolving dead code can be an in-depth process requiring significant analysis.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MSC07-C

Low

Unlikely

Medium

P2

L3

Automated Detection

Tool

Version

Checker

Description

CodeSonar
5.1p0

DIAG.UNEX.*
LANG.STRUCT.RC
LANG.STRUCT.UC

Code not exercised by analysis
Redundant condition
Unreachable {Call, Computation, Conditional, Control Flow, Data Flow}

Coverity

2017.07

DEADCODE


UNREACHABLE

Can detect the specific instance where code can never be reached because of a logical contradiction or a dead "default" in switch statement

Can detect the instances where code block is unreachable because of the syntactic structure of the code

GCC
4.3.5


Can detect violations of this recommendation when the -Wunreachable-code flag is used

Klocwork
2018

LA_UNUSED
UNREACH.GEN
UNREACH.RETURN
UNREACH.SIZEOF
INVARIANT_CONDITION.UNREACH


LDRA tool suite
9.7.1

1 J
139 S
140 S

Fully implemented

Parasoft C/C++test
10.4.2

CERT_C-MSC07-a
CERT_C-MSC07-b
CERT_C-MSC07-c
CERT_C-MSC07-d
CERT_C-MSC07-e
CERT_C-MSC07-f
CERT_C-MSC07-g
CERT_C-MSC07-h

There shall be no unreachable code in "else" block
There shall be no unreachable code after 'return', 'break', 'continue', and 'goto' statements
There shall be no unreachable code in "if/else/while/for" block
There shall be no unreachable code in switch statement
There shall be no unreachable code in 'for' loop
There shall be no unreachable code after 'if' or 'switch' statement
There shall be no unreachable code after "if" or "switch" statement inside while/for/do...while loop
Avoid switch with unreachable branches

Polyspace Bug Finder

R2019b

CERT C: Rule MSC07-C


Checks for:

  • Code does not execute
  • Default case is missing and may be reached
  • Code following control-flow statements


PRQA QA-C
9.5

1501, 1503, 2008, 2877, 2880, 2881,

2882, 2883, 2980, 2981, 2982, 2983,

2984, 2985, 2986, 3202, 3203, 3205,

3206, 3207, 3210, 3219, 3229, 3404,

3422, 3423, 3425, 3470

Fully implemented
SonarQube C/C++ Plugin
 3.11

S1763, S1751


Splint
3.1.1


Can detect violations of this recommendation when the -Wunreachable-code flag is used

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

SEI CERT C++ Coding StandardVOID MSC07-CPP. Detect and remove dead code
ISO/IEC TR 24772Unspecified functionality [BVQ]
Dead and deactivated code [XYQ]
MISRA C:2012Rule 2.1 (required)
MITRE CWECWE-561, Dead code

Bibliography

[Fortify 2006]Code Quality, "Dead Code"





7 Comments

  1. I don't believe the second non-compliant example is dead code. All the code is executed. It's may be an error of omission.

    Perhaps you meant to have a (stri+1 == NULL) conditional in there?

    1. As currently written, there is dead code in the second non-compliant example:

       int string_loop(char *str) {
          size_t i;
          for (i=0; i < strlen(str); i++) {
              /* ... */
      	if (str[i] == '\0')
      	    /* This code is never reached */
          }
          return 0;
      }
      

      Assuming that nothing adds zeroes into the middle of the string, then i is constrained to range over values for which str[i] is non-zero by virtue of the definition of what strlen() does.

      However, there is also an as yet unremarked upon performance bug in the code - calling strlen() on each iteration of the loop is wasteful unless you are busy adding or removing zeroes ('\0') from the data in str.  At one time (about 2 decades ago), Sun had a bug in their implementation of strstr() which evaluated strlen() on each iteration in strstr().  That didn't matter much of the time - but was disastrous when working with 20 KB long strings and chasing substrings that appeared every few hundred characters.

  2. While compliant solution 1 might be the correct solution, it is more likely (IMNSHO) that the correct course of action was to remove the second 'if (s)' and its associated block.  At the very least, this should be mentioned as a plausible alternative course of action.

    1. I think it's okay as is.  Of course we don't know what the actual intent was, but presumably the programmer thought the code would be of some use or he wouldn't have bothered to write it.

  3. In MISRA C:2012 parlance, this appears to be called "unreachable code".

  4. I'm thinking we should deprecate this guideline and combine with MSC12-C. Detect and remove code that has no effect.

  5. The -Wunreachable-code has been removed, because it was unstable: it relied on the optimizer, and so different versions of gcc would warn about different code.  The compiler still accepts and ignores the command line option so that existing Makefiles are not broken.  In some future release the option will be removed entirely.