Main Content

MISRA C:2012 Rule 2.2

A project shall not contain dead code

expand all in page

Description

Rule Definition

A project shall not contain dead code.

Rationale

If an operation is reachable but removing the operation does not affect program behavior, the operation constitutes dead code.

The presence of dead code can indicate an error in the program logic. Because a compiler can remove dead code, its presence can cause confusion for code reviewers.

Polyspace Implementation

The rule checker reports rule violations on operations whose removal does not affect program behavior. The most common situation is an operation whose result is not used subsequently. For instance:

  • You might perform an operation but not assign the result to a variable, even a temporary one.

  • You might assign the result of an operation to a variable but not use the variable subsequently.

  • You might assign a value to a variable and but not use the value subsequently. For more details, see Write without a further read.

  • You might assign the result of an operation to a variable but immediately afterward overwrite the variable value.

Other less common situations include calls to empty functions or redundant constant operations. Some of these operations involving constants occur in generated code and might be optimized away by your compiler. For instance, the operation 2u * 1u is a redundant operation that a compiler is likely to optimize to 2u. That is, the operation is unlikely to happen at run time. Irrespective of possible compiler optimizations, the rule checker reports a violation on the operation.

Polyspace® does not report a violation of this rule on:

  • Declaration of an unused parameter. Unused definitions are violations of MISRA C:2012 Rule 2.3.

  • Unused return of a non-void function because the function might have other side effects besides returning a value. Removing the function call might impact program behavior.

  • A cast operator whose result is used in the code.

Troubleshooting

If you expect a rule violation but do not see it, refer to Diagnose Why Coding Standard Violations Do Not Appear as Expected.

Examples

expand all

extern volatile unsigned int v;
extern char *p;

void f ( void ) {
    unsigned int x;


    ( void ) v;      /* Compliant - Exception*/
    ( int ) v;       /* Non-compliant  */
    v >> 3;          /* Non-compliant  */

    x = 3;           /* Non-compliant  */

    *p++;            /* Non-compliant  */
    ( *p )++;        /* Compliant  */
}

In this example, the rule is violated when an operation is performed on a variable, but the result of that operation is not used. For instance,

  • The operations (int) and >> on the variable v are redundant because the results are not used.

  • The operation = is redundant because the local variable x is not read after the operation.

  • The operation * on p++ is redundant because the result is not used.

The rule is not violated when:

  • A variable is cast to void. The cast indicates that you are intentionally not using the value.

  • The result of an operation is used. For instance, the operation * on p is not redundant, because *p is incremented.

void g ( void ) {
               /* Compliant  */
}

void h ( void) {
     g( );     /* Non-compliant */
}

In this example, g is an empty function. Though the function itself does not violate the rule, a call to the function violates the rule.

Check Information

Group: Unused Code
Category: Required
AGC Category: Required

Version History

Introduced in R2014b

expand all

See Also

| |

Topics