Skip to end of metadata
Go to start of metadata

The C++ Standard, [basic.types], paragraph 9 [ISO/IEC 14882-2014], states the following:

The object representation of an object of type T is the sequence of N unsigned char objects taken up by the object of type T, where N equals sizeof(T). The value representation of an object is the set of bits that hold the value of type T.

The narrow character types (charsigned char, and unsigned char)—as well as some other integral types on specific platforms—have an object representation that consists solely of the bits from the object's value representation. For such types, accessing any of the bits of the value representation is well-defined behavior. This form of object representation allows a programmer to access and modify an object solely based on its bit representation, such as by calling std::memcmp() on its object representation.

Other types, such as classes, may not have an object representation composed solely of the bits from the object's value representation. For instance, classes may have bit-field data members, padding inserted between data members, a vtable to support virtual method dispatch, or data members declared with different access privileges. For such types, accessing bits of the object representation that are not part of the object's value representation may result in undefined behavior depending on how those bits are accessed.

Do not access the bits of an object representation that are not part of the object's value representation. Even if the bits are accessed in a well-defined manner, such as through an array of unsigned char objects, the values represented by those bits are unspecified or implementation-defined, and reliance on any particular value can lead to abnormal program execution.

Noncompliant Code Example

In this noncompliant code example, the complete object representation is accessed when comparing two objects of type S. Per the C++ Standard, [class], paragraph 13 [ISO/IEC 14882-2014], classes may be padded with data to ensure that they are properly aligned in memory. The contents of the padding and the amount of padding added is implementation-defined. This can lead to incorrect results when comparing the object representation of classes instead of the value representation, as the padding may assume different unspecified values for each object instance.

#include <cstring>
 
struct S {
  unsigned char buffType;
  int size;
};
 
void f(const S &s1, const S &s2) {
  if (!std::memcmp(&s1, &s2, sizeof(S))) {
    // ...
  }
}

Compliant Solution

In this compliant solution, S overloads operator==() to perform a comparison of the value representation of the object.

struct S {  
  unsigned char buffType;
  int size;
 
  friend bool operator==(const S &lhs, const S &rhs) {
    return lhs.buffType == rhs.buffType &&
           lhs.size == rhs.size;
  }
};
 
void f(const S &s1, const S &s2) {
  if (s1 == s2) {
    // ...
  }
}

Noncompliant Code Example

In this noncompliant code example, std::memset() is used to clear the internal state of an object. An implementation may store a vtable within the object instance due to the presence of a virtual function, and that vtable is subsequently overwritten by the call to std::memset(), leading to undefined behavior when virtual method dispatch is required.

#include <cstring>

struct S {
  int i, j, k;
 
  // ...

  virtual void f();
};

void f() {
  S *s = new S;
  // ...
  std::memset(s, 0, sizeof(S));
  // ...
  s->f(); // undefined behavior
}

Compliant Solution

In this compliant solution, the data members of S are cleared explicitly instead of calling std::memset().

struct S {
  int i, j, k;
 
  // ...

  virtual void f();
  void clear() { i = j = k = 0; }
};

void f() {
  S *s = new S;
  // ...
  s->clear();
  // ...
  s->f(); // ok
}

Exceptions

EXP62-CPP-EX1: It is permissible to access the bits of an object representation when that access is otherwise unobservable in well-defined code. Specifically, reading bits that are not part of the value representation is permissible when there is no reliance or assumptions placed on their values, and writing bits that are not part of the value representation is only permissible when those bits are padding bits. This exception does not permit writing to bits that are part of the object representation aside from padding bits, such as overwriting a vtable pointer.

For instance, it is acceptable to call std::memcpy() on an object containing a bit-field, as in the following example, because the read and write of the padding bits cannot be observed. 

#include <cstring>
 
struct S {
  int i : 10;
  int j;
};
 
void f(const S &s1) {
  S s2;
  std::memcpy(&s2, &s1, sizeof(S));
}

Code that complies with this exception must still comply with OOP57-CPP. Prefer special member functions and overloaded operators to C Standard Library functions.

 Risk Assessment

The effects of accessing bits of an object representation that are not part of the object's value representation can range from implementation-defined behavior (such as assuming the layout of fields with differing access controls) to code execution vulnerabilities (such as overwriting the vtable pointer).

Rule

Severity

Likelihood

Remediation Cost

Priority

Level

EXP62-CPP

High

Probable

High

P6

L2

Automated Detection

Tool

Version

Checker

Description

LDRA tool suite
9.7.1

 

618 S

Partially implemented

Parasoft C/C++test

10.4.2

CERT_CPP-EXP62-a

Do not compare objects of a class that may contain padding bits with C standard library functions

PVS-Studio

6.23

V598, V780

Related Vulnerabilities

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

Related Guidelines

Bibliography

[ISO/IEC 14882-2014]Subclause 3.9, "Types"
Subclause 3.10, "Lvalues and Rvalues"
Clause 9, "Classes" 



  


3 Comments

  1. My other comments are now resolved, but I found two more:

    Some types—for example, integral types such as int and wchar_t—have an object representation composed solely of the bits from the object's value representation.

    • For C, this is only true for unsigned char...all other integer types are allowed to have padding bits. Is this also true for C++?
    • Good to provide a link explaining what a vtable is, but the link should be to something more authoritative than Wikipedia. Ideally, to a reference in our bibliography.
    1. > For C, this is only true for unsigned char...all other integer types are allowed to have padding bits. Is this also true for C++?

      Good catch, that was my mistake (see [basic.fundamental]p1). I've corrected.

      > Good to provide a link explaining what a vtable is, but the link should be to something more authoritative than Wikipedia. Ideally, to a reference in our bibliography.

      I thought one of those linked to our definitions, but it seems that's not the case because we have no definition for vtable. I've corrected.

    2. FYI: at the WG14 meeting this week, I discussed whether this is actually only true for unsigned char in C with David Keaton, and that is not the case. The intent of 6.2.6.2 paragraphs 1 and 2 is to treat signed charunsigned char, and char the same.