The vulnerability as described in ISO/IEC TR 24772-1:2019 clause 6.17 is applicable to C++, as it is susceptible to errors resulting from the use of similarly appearing names. However, the language rules prevent using an identifier that has not been declared. There are two possible issues: the use of the identical name for different purposes (see clause 6.20 Identifier Name Reuse [YOW]) and the use of similar names for different purposes.
Item
and item
as distinct declared identifiers with different meanings.BigDog
and Big_Dog
are different identifiers. Multiple underscores or a leading underscore followed by an upper-case letter cause undefined behaviour [EWF], thus Big__Dog
and _BigDog
should not be used.item
and items
. However, C++ lets the programmer use the identifier item
for a single object of a type T
and the identifier items
for an object denoting a range of items of T
. The use of item
where items
was intended or vice versa usually will be detected by the compiler because of the type mismatch.Long_IdentifierA
and Long_IdentifierB
are always different if the documented identifier limit is at least 16 characters.C++ permits the use of names such as x
, xx
, and xxx
, possibly defined in non-obvious scopes, and a programmer can easily, by mistake, write xx
where x
or xxx
was intended. Especially for overloaded functions, argument-dependent-lookup might find a function in a scope that the user did not consider. The use of the wrong name will typically result in a failure to compile so no vulnerability will arise. However, if the wrong name has a type compatible with the intended name’s type, then an incorrect executable program will be generated.
C++ defines reserves some names as context-specific keywords. While it is technically possible to use those names for other purposes, such use can be confusing.
In the global scope some namespaces (such as std
, posix
) are reserved and should not be used otherwise.
To avoid the vulnerability or mitigate its ill effects, C++ software developers can:
Use the avoidance mechanisms of ISO/IEC 24772-1:2019 clause 6.17.5.
Follow the rules of ISO/IEC 14882:2020 clause [lex.name] regarding names to refrain from usage.
Avoid the use of similar names to denote different objects of the same type.
Use consistency in choosing names, especially for dealing with similar names.
Use static analysis and tooling to enforce project-specific naming rules and detect possible similar names, for example, homoglyphs and unexpected text-direction vulnerabilities.
Keep the scope of names as small as reasonable.
Ensure that the names in your program do not exceed the compiler’s documented limit.
Do not differentiate names through only a mixture of case or the presence/absence of an underscore character.
Do not use as identifiers the contextual keywords final
, import
, module
and override
and other reserved names.