...
| Page properties | ||
|---|---|---|
| ||
I am uncertain whether it would be interesting or not, but another NCCE/CS pair that is specific to Microsoft Visual Studio would be the generic text mappings use by a lot of Win32 APIs (and Windows code in general). The IDE gives you a flag that you can toggle that specifies whether
I hesitate to add this as an NCCE/CS pair because it's so implementation-specific and I think the point is already made with other examples in this rule. However, this is one of those scenarios that can bite Win32 programmers if they're not observant, and the flag is relatively hidden. |
Noncompliant Code Example
In this noncompliant code example, the constant object n has internal linkage but is odr-used within f(), which has external linkage. Because f() is declared as an inline function, the definition of f() must be identical in all translation units. However, each translation unit has a unique instance of n, resulting in a violation of the One Definition Rule.
| Code Block | ||||
|---|---|---|---|---|
| ||||
const int n = 42;
int g(const int &lhs, const int &rhs);
inline int f(int k) {
return g(k, n);
} |
Compliant Solution
A compliant solution must change one of three factors: do not odr-use n within f(), declare n such that it has external linkage, or do not use an inline definition of f().
If circumstances allow modification of the signature of g() to accept parameters by value instead of by reference, then n will not be odr-used within f() because n would then qualify as a constant expression. While this results in a compliant solution, it is not ideal. It may not be possible (or desirable) to modify the signature of g(), such as std::max() from <algorithm>. Also, due to the differing linkage used by n and f(), accidental violations of the One Definition Rule are still likely if the definition of f() is modified to odr-use n.
| Code Block | ||||
|---|---|---|---|---|
| ||||
const int n = 42;
int g(const int &lhs, const int &rhs);
inline int f(int k) {
return g(k, n);
} |
In this compliant solution, the constant object n is replaced with an enumerator of the same name. Named enumerations defined at namespace scope have the same linkage as the namespace they are contained in. The global namespace has external linkage, and so the definition of the named enumeration, and its contained enumerators, also have external linkage. While less aesthetically pleasing, this compliant solution does not suffer from the same maintenance burdens of the previous code because n and f() have the same linkage.
| Code Block | ||||
|---|---|---|---|---|
| ||||
enum Constants {
n = 42
};
int g(const int &lhs, const int &rhs);
inline int f(int k) {
return g(k, n);
} |
Risk Assessment
Violating the ODR results in undefined behavior, which can result in exploits as well as denial-of-service attacks. As shown in "Support for Whole-Program Analysis and the Verification of the One-Definition Rule in C++" [Quinlan 06], failing to enforce the ODR enables a virtual function pointer attack known as the VPTR exploit. In this exploit, an object's virtual function table is corrupted so that calling a virtual function on the object results in malicious code being executed. See the paper by Quinlan and colleagues for more details. However, note that the attacker must have access to the system building the code to introduce the malicious class.
...