DCL01-A. Do not reuse variable names in subscopes

Do not use the same variable name in two scopes where one scope is contained in another. Examples include

• No other variable should share the name of a global variable if the other value 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.

Non-Compliant Code Example

This non-compliant code example reuses the msg identifier twice: at the start of the compilation unit (with file scope) and also 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 assign global variable and resulting in a potential buffer overflow.

char msg[100];
/* ... */
void report_error(char const *error_msg) {
  char msg[80];
  /* ... */
  /* Assume error_msg isn't too long */
  strcpy(msg, error_msg);
  return;
}

int main(void) {
  /* ... */
  /* Ensure error_msg isn't too long */
  if (strlen(error_msg) >= sizeof( msg)) {
    error_msg[sizeof(msg) - 1] = '\0';
  }
  report_error(error_msg); /* oops! */
  /* ... */
}

Compliant Solution

This compliant solution uses different, more descriptive variable names.

char system_msg[100];
/* ... */
void report_error(char const *error_msg) {
  char default_msg[80];
  /* ... */
  /* Assume error_msg isn't too long */
  strcpy(system_msg, error_msg);
  return;
}
int main(void) {
  /* ... */
  /* Ensure error_msg isn't too long */
  if (strlen(error_msg) >= sizeof(system_msg)) {
    error_msg[sizeof(msg) - 1] = '\0';
  }
  report_error(error_msg); /* good */
 /* ... */
}

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.

Risk Assessment

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

Automated Detection

The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.

Compass / ROSE currently does not detect violations of this recommendation. However, detecting violations should be easy. One merely has to note every variable declaration. If the variable is static, it should go into some global list. If the variable is not static, but its name exists in the global list, then the rule has been violated.

Related Vulnerabilities

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

References

[[ISO/IEC 9899:1999]] Section 5.2.4.1, "Translation limits"
[[ISO/IEC PDTR 24772]] "BRS Leveraging human experience" and "YOW Identifier name reuse"
[[MISRA 04]] Rule 5.2

DCL00-A. Const-qualify immutable objects      02. Declarations and Initialization (DCL)       DCL02-A. Use visually distinct identifiers