Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Note
titleDeprecated

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 06|AA. C References#Fortify 06]\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 -null value ends with a return statement.

Code Block
bgColor#FFCCCC
langc

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

...

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

Code Block
bgColor#ccccff
langc

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

...

In this example, the strlen() function is used to limit the number of times the function strings_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.

Code Block
bgColor#FFCCCC
langc

int strings_loop(char *strs) {
    size_t i;
    size_t len = strlen(strs);
    for (i=0; i < len; i++) {
        /* ... */
	  if (strs[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.

Code Block
bgColor#ccccff
langc

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

Exceptions

Anchor
MSC07-EX1
MSC07-EX1
MSC07-C-EX1: In some situations, seemingly dead code may make software resilient to future changes. An example of this is adding a default case to the default label in a switch statement even when all possible switch labels are specified (see whose controlling expression has an enumerated type and that specifies labels for all enumerations of the type. (See MSC01-C. Strive for logical completeness for an illustration of this example). .) 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.

Code Block
bgColor#ccccff
langc
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));
}

Anchor
MSC07-EX2
MSC07-EX2
MSC07-EX2: It is also permissible to temporarily remove code that may be needed later. (see 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

Low

unlikely

Unlikely

medium

Medium

P2

L3

Automated Detection

Tool

The LDRA tool suite Version 7.6.0 can detect violations of this recommendation.

Splint Version 3.1.1 can detect violations of this recommendation.

...

Version

Checker

Description

Astrée
Include Page
Astrée_V
Astrée_V
dead-assignemnt
dead-initializer
Partially checked and soundly supported.
CodeSonar
Include Page
CodeSonar_V
CodeSonar_V

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

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

Coverity

Include Page
Coverity_V
Coverity_V

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
Include Page
GCC_V
GCC_V


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

...

Helix QAC

Include Page
Helix QAC_V
Helix QAC_V

C1501, C1503, C2008, C2877, C2880, C2881, C2882, C2883,C3202, C3203, C3205, C3206, C3207, C3210, C3219, C3229, C3404, C3422, C3423, C3425, C3470

DF2877, DF2880, DF2881, DF2882, DF2883, DF2980, DF2981, DF2982, DF2983, DF2984, DF2985, DF2986


Klocwork
Include Page
Klocwork_V
Klocwork_V

LA_UNUSED
UNREACH.GEN
UNREACH.RETURN
UNREACH.SIZEOF

UNREACH.ENUM
INVARIANT_CONDITION.UNREACH


LDRA tool suite
Include Page
LDRA_V
LDRA_V

1 J
139 S
140 S

Fully implemented

Parasoft C/C++test
Include Page
Parasoft_V
Parasoft_V

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
CERT_C-MSC07-i

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
Avoid unreachable methods

Polyspace Bug Finder

Include Page
Polyspace Bug Finder_V
Polyspace Bug Finder_V

CERT C: Rule MSC07-C


Checks for:

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


RuleChecker
Include Page
RuleChecker_V
RuleChecker_V

dead-assignemnt
dead-initializer

Partially checked
SonarQube C/C++ Plugin
 
Include Page
SonarQube C/C++ Plugin_V
SonarQube C/C++ Plugin_V

S1763, S1751


Splint
Include Page
Splint_V
Splint_V


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

Klocwork Version 8.0.4.16 can detect violations of this rule with the LV_UNUSED.DEAD, PA_UNUSED.DEAD, UNREACH.BREAK, UNREACH.GEN, UNREACH.RETURN, and UNREACH.RETURN0 checkers.

Related Vulnerabilities

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

Other Languages

...

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

...

References

...

...

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"


...

Image Added Image Added Image Added PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "BRS Leveraging human experience," "BVQ Unspecified Functionality," and "XYQ Dead and Deactivated Code" \[[MISRA 04|AA. C References#MISRA 04]\] Rule 2.4 \[[MITRE 07|AA. C References#MITRE 07]\] [CWE ID 561|http://cwe.mitre.org/data/definitions/561.html], "Dead Code"MSC06-C. Be aware of compiler optimization when dealing with sensitive data      49. Miscellaneous (MSC)       MSC08-C. Library functions should validate their parameters