Page History

* No other variable should share the name of a global variable if the other variable is in a subscope of the global variable.

* A block should not declare a variable with the same name as a variable declared in any block that contains it.

Reusing variable names leads to programmer confusion about which variable is being modified. Additionally, if variable names are reused, generally one or both of the variable names are too generic.

h2.

 Noncompliant Code Example

This noncompliant code example declares the {{msg}} identifier at the start of the compilation unit (with file scope) and reuses the same identifier to declare a character array local to the {{report_error()}} function.  Consequently, the programmer unintentionally copies a string to the locally declared {{msg}} array within the {{report_error()}} function, failing to initialize the global {{msg}} variable and resulting in a potential buffer overflow.

{code

:bgColor

=#FFCCCC

}
char msg[100];

void report_error(const char *error_msg) {
  char msg[80];
  /* ... */
  strncpy(msg, error_msg, sizeof(msg));
  return;
}

int main(void) {
  char error_msg[80];
  /* ... */
  report_error(error_msg);
  /* ... */
}
{code}

h2. Compliant Solution

This compliant solution uses different, more descriptive variable names.

{code

:bgColor

=#ccccff

}
char system_msg[100];

void report_error(const char *error_msg) {
  char default_msg[80];
  /* ... */
  if (error_msg)
    strncpy(system_msg, error_msg, sizeof(system_msg));
  else
    strncpy(system_msg, default_msg, sizeof(system_msg));
  system_msg[ sizeof(system_msg) - 1] = '\0';
  return;
}

int main(void) {
  char error_msg[80];
  /* ... */
  report_error(error_msg);
  /* ... */
}
{code}
When the block is small, the danger of reusing variable names is mitigated by the visibility of the immediate declaration. Even in this case, however, variable name reuse is not desirable.

By using different variable names globally and locally, the compiler forces the developer to be more precise and descriptive with variable names.

h2.

 Risk Assessment

Reusing a variable name in a subscope can lead to unintentionally referencing an incorrect variable.

|| Recommendation || Severity || Likelihood || Remediation Cost || Priority || Level ||
| DCL01-C | low | unlikely | medium | {color:green}{*}P2{*}{color} | {color:green}{*}L3{*}{color} |

h3. Automated Detection

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.

Compass/ROSE can detect violations of this recommendation.

Klocwork Version 8.0.4.16 can detect violations of this rule with the *IF_MULTI_DECL*, *IF_MULTI_DEF*, and *IF_MULTI_KIND* checkers.

h3. Related Vulnerabilities

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

|https://www.kb.cert.org/vulnotes/bymetric?searchview&query=FIELD+KEYWORDS+contains+DCL01-C].

h3. Other Languages

This rule appears in the C+\+ Secure Coding Standard as [DCL01-CPP. Do not reuse variable names in subscopes|cplusplus:DCL01-CPP. Do not reuse variable names in subscopes].

This rule appears in the Java Secure Coding Standard as [SCP03-J. Do not reuse names|java:SCP03-J. Do not reuse names].

h2.

 References

\[[ISO/IEC 9899:1999|AA. C References#ISO/IEC 9899-1999]\] Section 5.2.4.1, "Translation limits"
\[[MISRA 04|AA. C References#MISRA 04]\] Rule 5.2

----
[!CERT C Secure Coding Standard^button_arrow_left.png!|DCL00-C. Const-qualify immutable objects]      [!CERT C Secure Coding Standard^button_arrow_up.png!|02. Declarations and Initialization (DCL)]      [!CERT C Secure Coding Standard^button_arrow_right.png!|DCL02-C. Use visually distinct identifiers]