Page History

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 removed from a programeliminated.

Non-Compliant Code Example 1

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 Wiki MarkupThis non-compliant code example demonstrates how dead code can be introduced into a program \[[Fortify 06|AA. C References#Fortify 06]\]. 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 that the situation appropriately. To correct the example abovepreceding noncompliant code, the return is removed from the body of the first conditional statement.

Code Block
bgColor #ccccff lang c
int func(int condition) { char *s = NULL; if (condition) { s = (char *)malloc(10); if (s == NULL) { /* Handle Errorerror */ } /* 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 strings_loop() will iterate. The conditional statement inside the loop is activated 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 lang c
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 lang c
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-CMSC00-EX1: In some situations, seemingly dead code may make software more robust against future changesresilient. 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 MSC01-Awhose 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 an illustration of this example).all those values, the default label is appropriate and necessary.

Code Block
bgColor #ccccff lang c
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 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 in to into a program and the effort required to remove it can be complex. Given thisAs a result, resolving dead code can be an in-depth process requiring significant changesanalysis.

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.

References

\[[Fortify 06|AA. C References#Fortify 06]\] Code Quality, "Dead Code"

  [ImperialViolet 2014]

Related Guidelines

Bibliography

...

Image Added Image Added Image AddedMSC06-A. Be aware of insecure compiler optimization when dealing with sensitive data      14. Miscellaneous (MSC)       MSC08-A. Library functions should validate their parameters