Page History

...

Do not violate the One Definition Rule; violations result in undefined behavior.

Noncompliant Code Example

In this noncompliant code example, two different translation units define a class of the same name with differing definitions. While the two definitions are functionally equivalent (they both define a class named S with a single, public, nonstatic data member int a), they are not defined using the same sequence of tokens. This is a violation of the ODR and results in undefined behavior.

// a.cpp
struct S {
  int a;
};
 
// b.cpp
class S {
public:
  int a;
};

Compliant Solution

The compliant solution depends on programmer intent. If the programmer intended for the same class definition to be visible in both translation units because of common usage, the solution is to use a header file to introduce the object into both translation units, as shown in this compliant solution:

...

Alternatively, the classes could be given distinct names in each translation unit to avoid violating the ODR.

Noncompliant Code Example

In this noncompliant code example, a class definition is introduced into two translation units using #include. However, one of the translation units uses a common, implementation-defined #pragma to specify structure field alignment requirements. Consequently, the two class definitions may have differing layouts in each translation unit, which is a violation of the ODR.

...

For more information on the behavior of #pragma pack, see the vendor documentation for your implementation, such as Microsoft Visual Studio or GCC.

Compliant Solution

In this compliant solution, the implementation-defined structure member alignment directive is removed, ensuring that all definitions of S do not violate the ODR:

...

struct S {
  TCHAR Buffer[1024];
};

Risk Assessment

Violating the One Definition Rule results in undefined behavior, which can result in exploits as well as denial-of-service attacks. As the paper by Quinlan et al. shows [Quinlan 06], failing to enforce the ODR enables a virtual function pointer attack, known as the VPTR exploit. This is where 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 et al. for more details. However, note that the attacker must have access to the system building the code to introduce the malicious class.

Automated Detection

Related Vulnerabilities

Search for vulnerabilities resulting from the violation of this rule on the CERT website.

Related Guidelines

Bibliography

...