According to subclause 6.2.7 of the C Standard [ISO/IEC 9899:2011],
All declarations that refer to the same object or function shall have compatible type; otherwise, the behavior is undefined.
(See also undefined behavior 15 of Annex J.)
Further, according to subclause 220.127.116.11,
Any identifiers that differ in a significant character are different identifiers. If two identifiers differ only in nonsignificant characters, the behavior is undefined.
(See also undefined behavior 31 of Annex J.)
Identifiers in mutually visible scopes must be deemed unique by the compiler to prevent confusion about which variable or function is being referenced. Implementations can allow additional nonunique characters to be appended to the end of identifiers, making the identifiers appear unique while actually being indistinguishable.
It is reasonable for scopes that are not visible to each other to have duplicate identifiers. For example, two functions can each have a local variable with the same name because their scopes cannot 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 (and from all included header files.)
To guarantee that identifiers are unique, 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:
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.
On implementations that support only the minimum requirements for significant characters required by the standard, this code example is noncompliant 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;
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;
In this noncompliant code example, both external identifiers consist of four universal character names. Because the first three universal character names of each identifier are identical, both identify the same integer array on implementations that support only the minimum requirements for significant characters required by the standard:
extern int *\U00010401\U00010401\U00010401\U00010401; extern int *\U00010401\U00010401\U00010401\U00010402;
For portability, the first three universal character name combinations used in an identifier must be unique:
extern int *\U00010401\U00010401\U00010401\U00010401; extern int *\U00010402\U00010401\U00010401\U00010401;
Nonunique identifiers can lead to abnormal program termination, denial-of-service attacks, or unintended information disclosure.
|Astrée||Supported indirectly via|
|Axivion Bauhaus Suite||CertC-DCL23|
Non-distinct identifiers: external names
Non-unique identifiers: external name
Global variable declared with different types
Can detect some violations of this rule but cannot flag violations involving universal names
|LDRA tool suite|
|Polyspace Bug Finder|
Rec. partially covered.
0627, 0776, 0777, 0778,
0779, 0789, 0791, 0793
|RuleChecker||Supported indirectly via|
|SonarQube C/C++ Plugin||IdentifierLongerThan31|
Search for vulnerabilities resulting from the violation of this rule on the CERT website.
|ISO/IEC TR 24772:2013||Choice of Clear Names [NAI]|
Identifier Name Reuse [YOW]
Rule 5.1 (required)
Subclause 6.2.7, "Compatible Type and Composite Type"