Code that has no effect or is never executed (that is, dead or unreachable code) is typically the result of a coding error and can cause unexpected behavior. Such code is usually optimized out of a program during compilation. However, to improve readability and ensure that logic errors are resolved, it should be identified, understood, and eliminated.
executed but does not perform any action, or has an unintended effect, most likely results from a coding error and can result in unexpected behavior. Statements or expressions that have no effect should be identified and removed from code. Most modern compilers, in many cases, can warn about code that has no effect in many cases (see or is never executed. (See MSC00-AC. Compile cleanly at high warning levels.)
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.
Code Block | ||||
---|---|---|---|---|
|
This recommendation is related to MSC07-A. Detect and remove dead code.
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;
}
|
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.
Code Block | ||||
---|---|---|---|---|
| ||||
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;
}
|
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.
Code Block | ||||
---|---|---|---|---|
| ||||
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;
}
|
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 | ||||
---|---|---|---|---|
| ||||
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;
}
|
Noncompliant
...
Code Example (Assignment)
In this noncompliant code example, the comparison of a
to b
has no effect.:
Code Block | ||||
---|---|---|---|---|
| ||||
int a;
int b;
/* ... */
a == b;
|
This is code is likely a case of the programmer mistakenly using the equals operator ==
instead of the assignment operator =
.
Compliant Solution (Assignment)
The assignment of b
to a
is now properly performed.:
Code Block | ||||
---|---|---|---|---|
| ||||
int a;
int b;
/* ... */
a = b;
|
...
Noncompliant Code Example (Dereference)
In this example, p
is incremented a pointer increment and then dereferenced. However, *p
a dereference occur, but the dereference has no effect.:
Code Block | ||||
---|---|---|---|---|
| ||||
int *p;
/* ... */
*p++;
|
Compliant Solution (Dereference)
Correcting this example depends on the intent of the programmer. For instanceexample, if dereferencing p
was a mistake, then p
should not be dereferenced.
Code Block | ||||
---|---|---|---|---|
| ||||
int *p; /* ... */ p++p; |
If the intent was to increment the value referred to by p
, then parentheses can be used to ensure p
is dereferenced and then incremented. (see See EXP00-C. Use parentheses for precedence of operation.).
Code Block | ||||
---|---|---|---|---|
| ||||
int *p;
/* ... */
(*p)++;
|
Compliant Solution (Memory Mapped Devices)
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
.
Code Block | ||||
---|---|---|---|---|
| ||||
volatile int *p; /* ... */ (void) *(p++); |
Noncompliant Code Example (if/else if)
A chain of if/else if statements is evaluated from top to bottom. At most, only one branch of the chain will be executed: the first one with a condition that evaluates to true. Consequently, duplicating a condition in a sequence of if/else if statements automatically leads to dead code.
Code Block | ||||
---|---|---|---|---|
| ||||
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)
In this compliant solution, the third conditional expression has been corrected.
Code Block | ||||
---|---|---|---|---|
| ||||
if (param == 1)
openWindow();
else if (param == 2)
closeWindow();
else if (param == 3)
moveWindowToTheBackground();
|
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.
Code Block | ||||
---|---|---|---|---|
| ||||
if (getc() == ':')
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 example, the rightmost subexpression of the controlling expression of each if
statement has no effect.
Code Block | ||||
---|---|---|---|---|
| ||||
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 first one is true, the second one is too
do_w();
}
|
Compliant Solution (logical operators)
In this compliant solution, the rightmost subexpression of the controlling expression of each if
statement has been removed.
Code Block | ||||
---|---|---|---|---|
| ||||
if (a == b) {
do_x();
}
if (a == c) {
do_w();
}
|
Noncompliant Code Example (Unconditional Jump)
Unconditional jump statements typically has no effect.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h>
for (int i = 0; i < 10; ++i) {
printf("i is %d", i);
continue; // this is meaningless; the loop would continue anyway
}
|
Compliant Solution (Unconditional Jump)
The continue statement has been removed from this compliant solution.
Code Block | ||||
---|---|---|---|---|
| ||||
#include <stdio.h>
for (int i = 0; i < 10; ++i) {
printf("i is %d", i);
}
|
Exceptions
Anchor | ||||
---|---|---|---|---|
|
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.Code Block | ||||
---|---|---|---|---|
| ||||
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 | ||||
---|---|---|---|---|
|
Anchor | ||||
---|---|---|---|---|
|
#ifdef
ed out does not violate this guideline, on the grounds that it could be subsequently used in another application, or built on a different platform.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.
Recommendation | Severity | Likelihood | Remediation Cost | Priority | Level |
---|---|---|---|---|---|
MSC12- |
C |
Low |
Unlikely |
Medium | P2 | L3 |
Automated Detection
...
The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.
Splint Version 3.1.1 can detect violations of this recommendation.
Tool | Version | Checker | Description | ||||||
---|---|---|---|---|---|---|---|---|---|
Astrée |
| dead-assignment | Supported + partially checked | ||||||
CodeSonar |
| DIAG.UNEX.* | Code not exercised by analysis | ||||||
| NO_EFFECT
DEADCODE
UNREACHABLE | Finds |
...
statements or expressions that do not accomplish anything |
...
or statements that perform an unintended action. Can detect the specific instance where code can never be reached because of a logical contradiction or a dead "default" in Can detect the instances where code block is unreachable because of the syntactic structure of the code | |||||||||
| CC2.MSC12 | Partially implemented | |||||||
GCC | 3.0 | Options detect unused local variables, nonconstant static variables and unused function parameters, or unreachable code respectively. | |||||||
Helix QAC |
| C3110, C3112, C3307, C3404, C3426, C3427 | |||||||
Klocwork |
| CWARN.NOEFFECT.SELF_ASSIGN CWARN.NOEFFECT.UCMP.GE CWARN.NOEFFECT.UCMP.GE.MACRO CWARN.NOEFFECT.UCMP.LT CWARN.NOEFFECT.UCMP.LT.MACRO CWARN.NULLCHECK.FUNCNAME EFFECT MISRA.STMT.NO_EFFECT UNREACH.GEN UNREACH.RETURN UNREACH.SIZEOF UNREACH.ENUM LA_UNUSED VA_UNUSED.GEN VA_UNUSED.INIT INVARIANT_CONDITION.UNREACH | |||||||
LDRA tool suite |
| 8 D, 65 D, 105 D, I J, 139 S, 140 S, 57 S | Partially implemented | ||||||
Parasoft C/C++test |
| CERT_C-MSC12-a | There shall be no unreachable code in "else" block | ||||||
PC-lint Plus |
| 438, 474, 505, 522, 523, | Fully supported | ||||||
Polyspace Bug Finder |
| Checks for:
Rec. partially covered. | |||||||
RuleChecker |
| dead-assignment | Partially checked | ||||||
SonarQube C/C++ Plugin |
| S1764, S2589, S2583, S1116, S1172, S1763, S1862, S1065, S1656, S2754, S1751 | |||||||
Splint |
| | The default mode checks for unreachable code. | ||||||
| V551, V606, V649, V779 |
Related Vulnerabilities
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
References
unmigratedCVE-wiki-markup
\[[Coverity 07|AA. C References#Coverity 07]\]
\[[ISO/IEC PDTR 24772|AA. C References#ISO/IEC PDTR 24772]\] "BRS Leveraging human experience," "BVQ Unspecified Functionality," "KOA Likely incorrect expressions," and "XYQ Dead and Deactivated Code"
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 14.1 and Rule 14.2
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 Standard | VOID MSC12-CPP. Detect and remove code that has no effect |
ISO/IEC TR 24772 | Unspecified Functionality [BVQ] Likely Incorrect Expressions [KOA] Dead and Deactivated Code [XYQ] |
MISRA C:2012 | Rule 2.2 (required) |
Bibliography
[Fortify 2006] | Code Quality, "Dead Code" |
[Coverity 2007] |
...
MSC11-A. Incorporate diagnostic tests using assertions 13. Miscellaneous (MSC) MSC13-A. Detect and remove unused values