Page History

...

The most common approach to multi-translation multitranslation unit compilation involves declarations residing in a header file that is subsequently made available to a source file via #include. These declarations are often also definitions, such as class and function template definitions. This approach is allowed by an exception defined in paragraph 6, which reads in part:

There can be more than one definition of a class type, enumeration type, inline function with external linkage, class template, non-static function template, static data member of a class template, member function of a class template, or template specialization for which some template parameters are not specified in a program provided that each definition appears in a different translation unit, and provided the definitions satisfy the following requirements. Given such an entity named D defined in more than one translation unit, then...

If the definitions of D satisfy all these requirements, then the program shall behave as if there were a single definition of D. If the definitions of D do not satisfy these requirements, then the behavior is undefined.

The requirements specified by paragraph 6 essentially state that that two definitions must be identical (not simply equivalent). Consequently, a definition introduced in two separate translation units by an #include directive generally will not violate the ODR due to because the definitions being are identical in both translation units.

However, it is possible to violate the ODR of a definition introduced via #include using block language linkage specifications, vendor-specific language extensions, etcand so on. A more likely scenario for ODR violations are is that accidental definitions of differing objects will exist in different translation units.

...

In this noncompliant code example, two different translation units define a class of the same name with differing definitions. While Although 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 code example violates the ODR and results in undefined behavior.

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

...

The compliant solution depends on programmer intent. If the programmer intended intends 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:

...

Implementation Details

It is possible for the above preceding noncompliant code example to result in a.cpp allocating space for an object with a different size than expected by init_s() in s.cpp. When translating s.cpp, the layout of the structure may include padding bytes between the c and a data members. When translating a.cpp, the layout of the structure may remove those padding bytes as a result of the #pragma pack directive, and so the object passed to init_s() may be smaller than expected. As a result, when init_s() initializes the data members of s, it may result in a buffer overrun.

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

...

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

// s.h
struct S {
  char c;
  int a;
};
 
void init_s(S &s);
 
// s.cpp
#include "s.h"
 
void init_s(S &s); {
  s.c = 'a';
  s.a = 12;
}
 
// a.cpp
#include "s.h"
 
void f() {
  S s;
  init_s(s);
}

...

Risk Assessment

Violating the One Definition Rule ODR 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.

...

Related Vulnerabilities

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

Related Guidelines

Bibliography

...