Identifiers in mutually visible scopes must be deemed unique by the compiler, in order to prevent confusion about which variable or function is being referenced. Implementations can allow additional non-unique characters to be appended to the end of identifiers, making the identifiers appear unique while actually being indistinguishable.
It is perfectly fine for scopes that are not visible to each other to have duplicate identifiers. For instance, two functions may each have a local variable with the same name, as their scopes can not access each other. But a function's local variable names should be distinct from each other, as well as from all static variables declared within the function's file (as well as all included header files.)
To guarantee identifiers are unique, first the number of significant characters recognized by (the most restrictive) compiler used must be determined. This assumption must be documented in the code.
The standard defines the following minimum requirements:
- 63 significant initial characters in an internal identifier or a macro name (each universal character name or extended source character is considered a single character)
- 31 significant initial characters in an external identifier (each universal character name specifying a short identifier of 0000FFFF or less is considered 6 characters, each universal character name specifying a short identifier of 00010000 or more is considered 10 characters, and each extended source character is considered the same number of characters as the corresponding universal character name, if any)
Restriction of the significance of an external name to fewer than 255 characters in the standard (considering each universal character name or extended source character as a single character) is an obsolescent feature that is a concession to existing implementations. As a result, it is not necessary to comply with this restriction, as long as the identifiers are unique and the assumptions concerning the number of significant characters are documented.
Non-Compliant Code Example (Source Character Set)
On implementations that support only the minimum requirements for significant characters required by the standard, the following example is non-compliant because the first 31 characters of the external identifiers are identical:
extern int *global_symbol_definition_lookup_table_a; extern int *global_symbol_definition_lookup_table_b;
Compliant Solution (Source Character Set)
In a compliant solution, the significant characters in each identifier must differ.
extern int *a_global_symbol_definition_lookup_table; extern int *b_global_symbol_definition_lookup_table;
Non-Compliant Code Example (Universal Characters)
In the following non-compliant code example, both external identifiers consist of four universal characters. Because the first three universal characters of each identifier are identical, both identify the same integer array.
extern int *\U00010401\U00010401\U00010401\U00010401; extern int *\U00010401\U00010401\U00010401\U00010402;
Compliant Solution (Universal Characters)
For portability, the first three universal character combination used in an identifier must be unique.
extern int *\U00010401\U00010401\U00010401\U00010401; extern int *\U00010402\U00010401\U00010401\U00010401;
Risk Assessment
Non-unique identifiers can lead to abnormal program termination, denial-of-service attacks, or unintended information disclosure.
Rule |
Severity |
Likelihood |
Remediation Cost |
Priority |
Level |
|---|---|---|---|---|---|
DCL32-C |
2 (medium) |
1 (unlikely) |
3 (low) |
P6 |
L2 |
Automated Detection
The LDRA tool suite V 7.6.0 is able to detect violations of this rule.
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]] "AJN Choice of Filenames and other External Identifiers" and "YOW Identifier name reuse"
[[MISRA 04]] Rules 5.1 and 8.9
02. Declarations and Initialization (DCL) DCL33-C. Ensure that restrict-qualified source and destination pointers in function arguments do not reference overlapping objects