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.