.CPP File Format – Undefined behaviour

Terminology

A program with undefined behaviour has no requirements placed on it, even for operations before the undefined one [intro.abstract]. Compilers use this to optimise: they may assume it never happens. Undefined behaviour during constant evaluation is a compile-time error, since such an expression is not a constant expression [expr.const].

Common undefined behaviour

std::unreachable() (C++23) and [[assume(expr)]] (C++23) deliberately invoke undefined behaviour, to tell the optimiser something. Sanitisers such as GCC’s and Clang’s -fsanitize=address,undefined and -fsanitize=thread find many of these at run time.

Object lifetime

An object’s lifetime begins when suitable storage is obtained and its initialisation is complete. It ends when its destructor call begins, or, for a type with a trivial destructor, when its storage is released or reused [basic.life].

Storage may outlast the object, or be obtained before it. Between these points, only limited use of a pointer to the storage is allowed. After the end of its lifetime, using an object through a pointer or reference is undefined behaviour.

const std::string& bad()
{
    std::string local = "gone";
    return local;                 // dangling reference: local dies at the return
}

int* p = new int(1);
delete p;
*p = 2;                           // undefined: use after free

std::vector<int> v{1, 2, 3};
auto it = v.begin();
v.push_back(4);                   // may reallocate
*it = 0;                          // undefined if it did

std::launder (C++17), in <new>, gives a usable pointer to an object created in storage that held another object of the same type, in the cases where the old pointer may not be used directly [ptr.launder].

struct Point { int x, y; };

auto* p = static_cast<Point*>(std::malloc(sizeof(Point)));
p->x = 1;                                 // fine since C++20

alignas(Point) std::byte buffer[sizeof(Point)];
auto* q = std::start_lifetime_as<Point>(buffer);   // C++23: keeps the bytes

Strict aliasing

An object may be accessed only through a type similar to one of these [basic.lval]:

• The object’s dynamic type.
• The signed or unsigned type corresponding to its dynamic type.
• char, unsigned char or std::byte.

Two types are similar if they differ only in const and volatile at any level [conv.qual]. Anything else is undefined behaviour, which lets the compiler assume that a pointer to float and a pointer to int do not point to the same object.

float f = 1.0f;
int a = *reinterpret_cast<int*>(&f);      // undefined: int is not similar to float

int b;
std::memcpy(&b, &f, sizeof b);            // fine: copies the object representation

auto c = std::bit_cast<int>(f);           // fine (C++20)

The memory model

A memory location is one object of scalar type, or one maximal run of adjacent bit-fields of non-zero width [intro.memory]. Two threads may update different memory locations without interfering. Since C++11 the language has a defined model for how threads interact [intro.multithread].

int counter = 0;
std::mutex m;

void racy()  { ++counter; }                     // undefined if run by two threads
void safe()  { std::lock_guard g(m); ++counter; }

std::atomic<int> shared{0};
void atomic_inc() { ++shared; }                 // defined