Skip to end of metadata
Go to start of metadata

The presence of unused values may indicate significant logic errors. To prevent such errors, unused values should be identified and removed from code.

This recommendation is a specific case of MSC12-C. Detect and remove code that has no effect or is never executed.

Noncompliant Code Example

In this example, p2 is assigned the value returned by bar(), but that value is never used. Note this example assumes that foo() and bar() return valid pointers (see DCL30-C. Declare objects with appropriate storage durations).

int *p1;
int *p2;
p1 = foo();
p2 = bar();

if (baz()) {
  return p1;
}
else {
  p2 = p1;
}
return p2;

Compliant Solution

This example can be corrected in many different ways, depending on the intent of the programmer. In this compliant solution, p2 is found to be extraneous. The calls to bar() and baz() can be removed if they do not produce any side effects.

int *p1 = foo();

/* Removable if bar() does not produce any side effects */
(void)bar();

/* Removable if baz() does not produce any side effects */
(void)baz();
return p1;

Exceptions

MSC13-EX1: Initializing a variable with a default value, such as 0, which gets subsequently overwritten may be inefficient, but is less of a problem than reading an uninitialized value, as per EXP33-C. Do not read uninitialized memory.

Risk Assessment

Unused values may indicate significant logic errors.

Recommendation

Severity

Likelihood

Remediation Cost

Priority

Level

MSC13-C

Low

Unlikely

Medium

P2

L3

Automated Detection

Tool

Version

Checker

Description

Astrée
19.04

Supported, but no explicit checker
CodeSonar
5.1p0

LANG.STRUCT.UUVAL

Unused value

Coverity

2017.07

UNUSED_VALUE

Finds variables that are assigned pointer values returned from a function call but never used

Klocwork
2018

LV_UNUSED.GEN
VA_UNUSED.GEN
VA_UNUSED.INIT


LDRA tool suite
9.7.1

1 D, 8 D, 105 D, 94 D, 15 D

Fully implemented

Parasoft C/C++test
10.4.2

CERT_C-MSC13-a

Avoid unnecessary local variables
Polyspace Bug Finder

R2019a

CERT C: Rec. MSC13-C


Checks for:

  • Unused parameter
  • Write without a further read

Rec. partially covered.

PRQA QA-C
9.5

1500, 1502, 2980, 2981, 2982,

2983, 2984, 2985, 2986, 3203,

3205, 3206, 3207, 3229

Fully implemented
PVS-Studio

6.23

V519, V596, V603, V714, V744, V751, V763, V1001
SonarQube C/C++ Plugin
3.11
S1854

Related Vulnerabilities

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

Related Guidelines

SEI CERT C++ Coding StandardVOID MSC13-CPP. Detect and remove unused values
ISO/IEC TR 24772Likely Incorrect Expressions [KOA]
Dead and Deactivated Code [XYQ]
Unused Variable [XYR]

Bibliography



5 Comments

  1. I'm uncomfortable with the examples, as the replacement is only possible if bar() has no side-effects. A few options:

    • Add a comment that you can only remove bar() if it has no side-effects
    • Add a bar() call on its own line, with a comment saying it's removable if there's no side-effects
    • Replace the call to bar() with inline code, such as p2 = &p1[3];, where its clear there are no side-effects.
    1. Agreed and fixed.

  2. Most compliers will issue warnings when variables are unused, and the compiler should always be asked to issue these warnings.

    They are not always easy to make go away when in #ifdef hell, but the approach I've taken in the past is to either delete the variable (if it's really unused), or to create some macros that tag the variable with the proper intent.

    /* common header file */
    #define UNUSED_PARAMETER(p)     (void)(p)       /* shut up compiler warnings */
    #define UNUSED_VARIABLE(p)     (void)(p)       /* shut up compiler warnings */
    

    Now one can do:

    void on_SIGALRM(int signo) {
       UNUSED_PARAMETER(signo);
       /* do something on the signal handler but we darn well know it's SIGALRM */
    }
    
    

    and not only shut up the compiler warnings, but tell the user "We really know this parameter is not used"

    Other examples could be - a contrived one:

    void myfunction(int i) {
    #ifdef _WIN32
      /* do stuff using i */
    #else
     /* do stuff with UNIX, that doesn't use i */
     UNUSED_PARAMETER(i);
    #endif
    }
     
    

    This allows max documentation of programmer intent, which conveys a valuable security message.

    The only reason for UNUSED_PARAMETER() and UNUSED_VARIABLE() is documentation; they do the same thing.

  3. What would be a good algorithm for ROSE to try and detect this? I thought at first that looking for two consecutive writes to a variable without an intervening read should set off a flag, but looking trough our code there seem to be plenty of cases in which that is not a violation...

  4. I think that the title and content of this recommendation should be modified to explicitly mention unreferenced formal parameters as well.