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
In this non-compliant code example, the programmer sets the value of the msg variable, expecting to reuse it outside the block. Due to the reuse of the variable name, however, the outside msg variable value is not changed.
char msg[100];
/* ... */
void error_message(char *error_msg) {
char msg[80];
/* ... */
/* Assume error_msg isn't too long */
strcpy(msg, error_msg);
return;
}
/* ... */
/* Ensure error_msg isn't too long */
if (strlen( error_msg) >= sizeof( msg)) {
error_msg[sizeof(msg) - 1] = '\0';
}
error_message( error_msg); /* oops! */
Furthermore, if the length of the null-terminated byte string referenced by error_msg is greater than 79 characters in length, a buffer overflow will occur on the stack, which may be exploitable. This occurs in spite of the outer function's attempt to prevent buffer overflow!
Compliant Solution
This compliant solution uses different, more descriptive variable names. Also it uses strcpy_s().
char system_msg[100];
/* ... */
void error_message(char *error_msg) {
char default_msg[80];
/* ... */
/* Assume error_msg isn't too long */
strcpy(system_msg, error_msg);
return;
}
/* ... */
/* Ensure error_msg isn't too long */
if (strlen( error_msg) >= sizeof( system_msg)) {
error_msg[sizeof(msg) - 1] = '\0';
}
error_message( 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 unintended values for the variable.
Recommendation |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
DCL01-A |
1 (low) |
1 (unlikely) |
2 (medium) |
P2 |
L3 |
Automated Detection
The LDRA tool suite V 7.6.0 is able to detect violations of this recommendation.
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"
[[MISRA 04]] Rule 5.2
DCL00-A. Declare immutable values using enum or const 02. Declarations and Initialization (DCL) DCL02-A. Use visually distinct identifiers