Undefined Behavior

Overview

Drawing on his own C/C++ experience, Thomas Habets argues that Undefined Behavior (UB) is widespread in nontrivial code. Here, "nontrivial" means code that goes beyond a few-line example and performs real functionality, where pointers, integer arithmetic, type casting, concurrency, and other features begin to intertwine. This document examines why UB in C/C++ cannot be attributed solely to individual carelessness. The fact that even an expert who has written C/C++ daily for nearly 30 years continues to run into UB shows that this is not a matter of individual skill, but something closer to a fundamental cost imposed by the language and its ecosystem.¹

Write it with a little flourish and you can define it as follows.

UB is not a problem caused by the compiler maliciously optimizing your code into failure. UB is the right it grants the compiler to assume that "such a situation will never occur."

Code containing UB runs on the premise that the compiler, ABI, hardware, and runtime all operate under the assumption that "no well-formed C code would ever do this." Even if a human reader finds the intent obvious, the issue arises because there may be no means to express that intent between compiler stages or across module boundaries. In other words, the way a computer and a human communicate is fundamentally different.

0. Terms Related to UB

When reading C/C++ standard documents, you need to distinguish between expressions that look similar. This is a chronic problem with C-family languages.

The C++ working draft also treats undefined behavior as "no requirements," explaining that possible outcomes range broadly from being ignored, to unpredictable execution, to termination with a diagnostic.² cppreference likewise lists out-of-bounds memory access, signed integer overflow, null pointer dereference, and strict aliasing violations as examples of C/C++ UB.³⁴

Distinctions:

• Implementation-defined behavior is a documented implementation choice. Risk remains.

• Unspecified behavior is one of several possible choices.

• UB has no fixed set of choices at all.

UB is broader in scope than "random results occur", it does not mean the program crashes in a bizarre way every single time. Code may appear to work under normal conditions, yet after changing the compiler version or optimization flags, that code path may be treated as impossible.

In other words, UB is called "undefined behavior" precisely because it is unpredictable.

1. -O0 does not turn UB into defined behavior

Passing -O0 (Optimization Level 0, the compiler flag that disables optimizations) does not transform UB into defined behavior. Developers often assume that "turning off all optimizations means the compiler translates source code one-to-one into machine code, so unpredictable behavior (UB) can be avoided", but this is a misconception.¹

The problem is that not all UB manifests in the same way. Why would it be undefined behavior in the first place? Let's start by splitting it into two broad categories.

First, UB that directly intersects with hardware or the ABI. Cases such as misaligned pointer access, out-of-bounds memory access, invalid function pointer calls, and accessing an object outside its valid lifetime can all result in crashes, traps, or stray memory accesses regardless of optimization level. In these cases, -O0 does not make the program safe; it only means the compiler is somewhat less likely to aggressively rewrite the code.

Second, UB that surfaces when compiler optimization passes treat it as a given. Examples include null check elimination, simplification of conditional expressions exploiting signed overflow, dead code elimination, and loop optimization. These transformations tend to be more visible at -O2, -O3, with LTO, or with target-specific optimizations. At -O0, the same code may appear to execute as intended on the surface. However, that does not mean the code has become defined behavior; it is closer to saying that, in that particular build, the UB has not yet been actively exploited.

This process can be likened to a game of "telephone." The intent of the source code is continuously transformed as it passes through the compiler's Intermediate Representation (IR), optimization stages, the ABI, and hardware instructions. Even if the code happens to behave as intended under -O0 today, there is no guarantee the same result will hold under a future compiler version or a different architecture.

The classic analysis from LLVM and John Regehr connects directly to this point: a compiler may assume that UB never occurs in a valid C/C++ program, and that assumption feeds directly into case analysis, dead code elimination, null check elimination, and loop optimization.⁵⁶

To be precise, UB is still UB even at -O0. It is just that aggressive code elimination and rewriting based on UB typically surface only when optimizations are enabled. Confusing the two makes it hard to counter the argument "but null checks don't get eliminated at -O0, do they?"

Consider the following code.

int *p = get_pointer();
int value = *p;          /* (1) Dereference succeeded = the compiler can assume `p` is non-null afterward */
if (p == NULL) {         /* (2) "Since the dereference succeeded, `p` cannot be `NULL`" */
        return -1;       /* (3) The entire branch is eliminated as dead code */
}
return value;            /* Because `value` is actually used, the load in (1) is not eliminated */

A human reader might interpret this as "read the pointer, and if it's null, return an error." But if p is null, UB already occurs at the dereference in (1). In other words, this code is not code that has a null check; it is code where the null check comes too late.

When optimizations are enabled, the situation becomes more severe. The compiler can conclude that in a valid program the dereference at (1) succeeded, and from that fact infer that p is not null. The subsequent if (p == NULL) branch can then be eliminated as dead code.

int *p = get_pointer(); 
int value = *p; 
return value;

Does this mean the compiler is maliciously removing defensive code? No. The C/C++ standard allows the compiler to interpret code under the assumption that null pointer dereference never occurs in a valid program. On a path that contains UB, "an unexpected value is produced" is less accurate than "that path may be treated as unreachable." The null check elimination example in the LLVM article takes exactly this form, and it has led to real vulnerabilities in the Linux kernel.⁶

For example, the fact that signed integer overflow is UB is not simply "the value might go wrong."

int greater_after_increment(int x)
{
        return x + 1 > x;
}

A human thinks that when x == INT_MAX, an overflow might corrupt the result. In C/C++, signed integer overflow is UB. The compiler may assume that in a valid program x + 1 does not overflow, and the function may be optimized to always return true.

In an optimized build, this function can be simplified as follows.

int greater_after_increment(int x)
{
        return 1;
}

At -O0, the actual addition and comparison may remain intact. However, that does not mean the x == INT_MAX input constitutes defined behavior. If signed integer overflow occurs on that input, the standard's guarantees no longer apply; it is simply that in that particular build the compiler chose not to fold the conditional expression by exploiting the UB.

The conclusion, therefore, is not "UB is caused by optimization settings," nor is it "UB always manifests the same way at -O0." Whether it surfaces as a hardware trap, silently proceeds by chance, or causes defensive code to vanish during an optimization pass is determined by the build configuration and the platform. And what makes this truly insidious is precisely that it works fine on your own machine.⁶

2. Common UB Cases

The cases below lurk in code that is far more ordinary than the commonly cited memory-safety trio (double-free, use-after-free, out-of-bounds access). This is not an exhaustive list; an exhaustive list would read less like documentation and more like an exorcism ritual.

Personal note: I think C programmers would do well to adopt a religion for the sake of their peace of mind.

2.1 Misaligned Pointer Access (C23 6.3.2.3)

int foo(const int *p)
{
        return *p;
}

If p does not satisfy the alignment requirement for int (typically an address that is a multiple of sizeof(int)), dereferencing it is UB and the outcome varies by platform.

• Linux on Alpha: on certain loads, the kernel receives a trap and emulates the intended behavior in software; on other loads, the process crashes with SIGBUS.

• SPARC: SIGBUS.

• x86/amd64: it works without issue in most cases and sometimes even appears to behave like an atomic read, because the hardware handles unaligned loads and stores itself.

Personal note: "It works on my machine" is the single most meaningless sentence you can utter in front of the C standard. Just because it ran quietly on x86 does not mean the standard has vouched for your code; it simply means the hardware that day had no complaints.

The compiler has absolutely no obligation to generate safe machine code for a misaligned pointer. It can, at any point, use optimization as justification for emitting a different load instruction, and at that moment the thin mercy the hardware had been granting disappears and the program responds immediately with a crash.

Atomicity is similar.

The moment you ask whether a store/load on a misaligned std::atomic<int> is atomic, you have already taken the wrong path. From the language-standard point of view, violating the object's alignment requirement is already UB, so the hardware atomicity discussion that follows is no longer about the meaning of standard C++ code. It is about what can happen on a particular implementation, ABI, and CPU.

That said, x86/amd64 still has its own hardware-level boundary. According to Intel's documentation, P6 and later processors perform unaligned 16-, 32-, and 64-bit accesses to cached memory atomically if the access fits entirely within a single cache line. Once the access crosses a cache-line boundary or a page boundary, it falls outside that guarantee.⁷

So the statement “atomicity can break when the object straddles a page boundary” is not wrong, but it would be more precise to write it as follows: split accesses that cross a cache-line boundary are not guaranteed to be atomic, and a page boundary is the more extreme split/fault case.

A LOCK-prefixed operation may trigger a split lock, bus lock, or strong serialization, but that is still a performance and implementation-detail issue. It does not make a misaligned std::atomic<T> standard-conforming C++.

More strictly speaking, the cast itself can be the problem.

bool parse_packet(const uint8_t *bytes)
{
        const int *magic_intp = (const int *)bytes;   /* ✗ UB already occurs here */
        int magic_raw = foo(magic_intp);              /* May crash on SPARC */
        int magic = ntohl(magic_raw);                 /* This line itself is fine */
        /* ... */
}

What makes this even more uncomfortable is that the issue is not limited to the dereference inside foo(). In C, converting an object pointer to a type for which it is incorrectly aligned is already UB. The naive assumption that "just casting is fine as long as you don't read" is exactly where the trouble starts.

7 A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned59) for the referenced type, the behavior is undefined.

(C23 6.3.2.3p7: if the resulting pointer from a conversion is not correctly aligned for the target type, the conversion itself is UB.)

In this C example, the problem can arise before reading or writing through the converted pointer (*p). C makes the misaligned object-pointer conversion itself undefined. C++ has separate object-pointer conversion rules, so the C rule must not be generalized to it. Converting a pointer to int * alone does not establish correct alignment or valid object access.

The UB in this example does not end with alignment alone. Reading the original uint8_t array through an int lvalue also violates the strict aliasing (effective type) rule (see section 2.7). Even if bytes happens to satisfy 4-byte alignment and thus avoids the alignment UB, the aliasing UB from reading through int remains independently. The reason code that casts a packet to an integer for parsing is dangerous is not that it breaks one rule, but that it steps on both alignment and effective type in the same line. The safe path is to copy the bytes in via memcpy.

2.2 The isxdigit(char) problem (C23 7.4, 6.2.5)

bool bar(char ch)
{
        return isxdigit(ch);   /* ✗ UB possible on platforms where char is signed */
}

In all cases the argument is an int, the value of which shall be representable as an unsigned char or shall equal the value of the macro EOF. If the argument has any other value, the behavior is undefined

Functions in the isxdigit family are defined to accept a value representable as unsigned char, or EOF. EOF is an int and is a negative value not representable as unsigned char. Therefore the argument type is int.

On platforms where char is signed (implementation-defined, 6.2.5), passing a byte value of 0x80 or higher converts it to a negative int, and a valid implementation like the following ends up reading from the wrong memory location.

int isxdigit(int c)
{
        if (c == EOF) {
                return false;
        }
        return some_array[c];   /* reads outside the array if `c` is negative */
}

If that memory happens to be an I/O-mapped region, the result may not end with a mere random value or crash. In an embedded environment, a motor could start spinning. If a machine physically moves because you called isxdigit() incorrectly once, you are entitled to go home that day, slide your C book under your pillow, and sleep on it.

The defensive form is as follows.

  /* Good example */
bool bar(char ch)
{
        return isxdigit((unsigned char)ch) != 0;   /* ✓ */
}

2.3 Converting float to int (C23 6.3.1.4)

int milliseconds(float seconds)
{
        int tmp = (int)(seconds * 1000.0);   /* ✗ Out-of-range access is UB */
        return tmp + 1;                       /* ✗ Signed integer overflow is also a separate UB */
}

If the value of the integral part cannot be represented by the integer type, the behavior is undefined.

When converting a finite floating-point value to an integer type, if the integer part cannot be represented in the target type, the behavior is undefined (6.3.1.4). By extension, non-finite values such as NaN and Infinity are also UB.

The tricky part is that even performing a safe comparison is not straightforward. Casting INT_MAX to float provides no guarantee of exact representation, so the comparison can be inaccurate. The defensive code looks like this.

int milliseconds(float seconds)
{
        const float ftmp = seconds * 1000.0f;

        if (!isfinite(ftmp)) {
                return 0;   /* or another error report */
        }
        if ((float)(INT_MIN + 1000) > ftmp) {
                return 0;
        }
        if ((float)(INT_MAX - 1000) < ftmp) {
                return 0;
        }

        /* Now safe to convert */
        const int tmp = (int)ftmp;
        if (INT_MAX == tmp) {
                return 0;
        }

        /* Now safe to add */
        return tmp + 1;
}

"I just wanted to convert seconds to milliseconds", and yet this much guard code is required. Even a quick scan of open-source projects turns up plenty of code that simply multiplies and casts without any such checks.

Personal note: At this point, C is a language that teaches you to check boundary conditions and avoid mistakes before it teaches you to calculate anything.

2.4 Address 0 and the Null Pointer (C23 6.3.2.3, 6.5.4.2)

There is no guarantee that NULL in the C standard (the null pointer constant, which is either the integer constant 0 or a value converted from nullptr) is identical to hardware address 0. This is because the standard operates strictly on top of the C abstract machine. The only guarantee provided is that "comparing NULL to 0 evaluates as equal," and that 0 may in fact be the result of converting to the platform's native NULL representation (for example, 0xffff).

Dereferencing such a null pointer is unambiguous UB. C standard section 6.5.4.2 states this as follows.

"If an invalid value has been assigned to the pointer, the behavior of the unary * operator is undefined."

The standard declares that dereferencing (*) a pointer holding an "invalid value" produces UB, and footnote 101 of that clause explicitly identifies the null pointer as the primary example of such an invalid value.

Due to this characteristic of the language, there are two traps that frequently appear in real-world practice.

memset(&ptr, 0, sizeof(ptr));   /* ✗ No guarantee that `ptr` becomes NULL */

You cannot assume that zeroing out a struct makes all member pointers NULL. This works on most modern platforms, but it is not a guarantee at the standard level.

void (*func_ptr)() = NULL;
func_ptr();   /* Calling through a pointer that does not point to a function: UB */

Dereferencing a null pointer is UB regardless of its value (6.5.4.2). Section 6.3.2.3 specifies that NULL is not equal to "any object or function," so even if a real object or vector table exists at address 0, standard C does not allow you to treat that location like an ordinary object. The idea of "just issue a call instruction with an all-zeroes bit pattern" also falls apart once the definition of "all zeroes" itself becomes ambiguous, as it does on 16-bit x86 where address 0 could mean 0000:0000 or CS:0000.

In OS kernel and embedded work, this is no joke.

Personal note: Ordinary application developers typically encounter address 0 as a bug, but kernel and embedded folks run into address 0 like a familiar neighbor. Sometimes they even stop in for a drink at the local bar.

2.5 Variadic Arguments and Type Mismatch

execl("/bin/sh", "sh", "-c", "date", NULL);   /* ✗ */
execl("/bin/sh", "sh", "-c", "date", 0);      /* ✗ */
execl("/bin/sh", "sh", "-c", "date", (char *)NULL);   /* ✓ */

The sentinel that terminates a variadic argument list must be a pointer type, but the NULL macro can be interpreted as the integer 0, so an explicit cast is required.

There is an ABI-level nuance here. On implementations where NULL is defined as ((void *)0) (which covers most POSIX systems), passing execl(..., NULL) does hand off a pointer, so it works in practice. The case that truly breaks is an LP64 environment where NULL is defined as the integer 0, int is 32 bits, and pointers are 64 bits. Variadic calls carry no type information, so the caller pushes a 32-bit int, while execl internally pulls a 64-bit pointer via va_arg(ap, char *). The width mismatch means the upper bits may contain garbage, and the sentinel may no longer be recognized as NULL. Casting to (char *)NULL ensures the value is passed at pointer width regardless of how NULL is defined.

uint64_t blah = 123;
printf("%ld\n", blah);   /* ✗ format and argument type mismatch = UB */

printf("%" PRIu64 "\n", blah);   /* ✓ */

uint64_t should be printed using macros such as PRIu64. For types whose signedness is implementation-defined, such as uid_t, the workaround is to cast to uintmax_t and print with PRIuMAX.

2.6 Division by Zero

Everyone knows that division by zero is UB, yet it comes up more often than you might expect. The denominator more frequently comes from untrusted input than people realize, and divide-by-zero can become an attack surface.

For reference, the C23 standard uses the word "undefined" 283 times. Behaviors that are undefined by omission are not even counted in that number.

Personal note: If "undefined" appears 283 times, that is perhaps not a warning but a philosophy.

2.7 Strict Aliasing

In C/C++, you cannot read an object through just any pointer type. When the compiler determines that two types cannot alias each other, it is allowed to assume that two pointers of those types do not point to the same memory.

int f(int *i, float *f)
{
        *i = 1;
        *f = 0.0f;
        return *i;
}

If you force i and f to point to the same address, it may look to a human reader as though *f = 0.0f would overwrite the bits of *i. Under the strict aliasing rule, however, an int * and a float * are generally not considered to point to the same object, so the compiler is free to treat return *i as return 1.

Using memcpy for byte copying is generally the safer workaround.

float read_float_from_bytes(const unsigned char bytes[sizeof(float)])
{
        float value;
        memcpy(&value, bytes, sizeof(value));
        return value;
}

char, unsigned char, and std::byte are treated as special channels for reading an object's representation. Code that reinterprets memory through arbitrary type pointers must follow separate rules.

2.8 Object Lifetime and Placement New

In C++, having a memory address does not mean a live object of the desired type exists at that location. An object's storage and its lifetime are distinct concepts.

alignas(std::string) unsigned char buffer[sizeof(std::string)];

auto *s = reinterpret_cast<std::string *>(buffer);
// *s must not be used here. The `std::string` object has not yet been started.

Actually creating an object requires a lifetime-starting operation such as placement new.

auto *s = new (buffer) std::string("hello");
std::cout << *s << "\n";
s->~basic_string();

C++'s object lifetime rules frequently cause issues when building allocators, arenas, serialization layers, ECS systems, and custom containers. "Having allocated the memory" and "having a live object of that type" are not the same thing.

2.9 Data Race

In C++, a data race is UB. If two threads access the same memory, at least one of those accesses is a write, and there is no appropriate synchronization, the entire program becomes undefined.

int counter = 0;

void worker()
{
        counter++;   // When multiple threads execute concurrently, a data race occurs
}

In such cases, use atomic types.

std::atomic<int> counter = 0;

void worker()
{
        counter.fetch_add(1, std::memory_order_relaxed);
}

The reason a data race is UB is not simply that values can be wrong. It is because the compiler and CPU are free to reorder memory accesses and hold values in registers. Consequently, a concurrent data race goes beyond a value error and steps outside the language model altogether.

2.10 Shift UB

Bit shifts are another common source of UB.

int x = 1 << 31;       /* UB possible if `int` is 32-bit */
int y = 1 << -1;       /* UB */
int z = 1 << 32;       /* UB if `int` is 32-bit */

Shifting by a negative count or by an amount greater than or equal to the type's width is UB. A left shift on a signed type that produces a result not representable in that type is also problematic. Bitwise code is better written using explicit unsigned types such as uint32_t or uint64_t, and shift counts should be validated before use.

Note that the rules for signed left shift differ in C++20.

3. Bonus: The Integer Promotion Trap

While not UB itself, integer promotion rules are difficult to evaluate quickly when skimming code. These rules silently convert what appears to be a small-type operation into an int operation.

unsigned char a = 0xff;
unsigned char b = 1;
unsigned char zero = 0;
bool overflowed = (a + b) == zero;
/* `overflowed` is 0 (false). `a` and `b` are promoted to `int`, becoming `0x100`, so they differ from `zero` */

unsigned char a = 0x80;
uint64_t b = a << 24;
/* Assumptions: 8-bit unsigned char, 32-bit int. */
/* C: the signed left shift is UB, so no value of b is guaranteed. */
/* C++17: the shift is allowed; conversion of its result to int is implementation-defined. */
/* Typical C++17 implementations and C++20+: b == 0xffffffff80000000. */
/* To get 0x80000000, convert to unsigned 64-bit before shifting. */
uint64_t safe = (uint64_t)a << 24;

Declaring the variables unsigned does not keep the shifted expression unsigned: the small operand is first promoted to int. If the shift produces a negative int, conversion to uint64_t yields a large unsigned value. Correctly applying promotion rules at skimming speed is practically impossible.

Assuming an 8-bit unsigned char and a 32-bit int, a << 24 exceeds the signed int range in C and is UB; a particular result is not guaranteed. C++17 uses a different rule: a non-negative signed operand may be shifted when the product fits the corresponding unsigned type, with the result then converted to int. That conversion is implementation-defined here. Common implementations produce a negative int, whose conversion to uint64_t gives the large value above. Since C++20, left-shift results are defined modulo the type's bit width. C23's two's-complement representation does not change C's signed left-shift overflow rule. Keep the language version and type widths explicit, and convert to an unsigned type before shifting, as in safe. C++17 draft 8.8 · C++20 draft 7.6.7

4. How Do Other Languages Handle This Cost?

UB in C/C++ cannot be explained away as "mistakes made by careless programmers." If even experts keep running into it over 30 years, I think we need to look at the fundamental costs built into the language and its ecosystem rather than attributing the problem to individual skill.

Other languages handle this cost primarily in one of four ways.

4.1 Rust

The type system and borrow checker block many UB categories from C/C++ at compile time. Array out-of-bounds access results in a panic rather than UB, and use-after-free, double-free, and data races are mostly prevented at the compilation stage in safe Rust.

let value = vec![1, 2, 3];
let x = value[10];   // Panic, not UB

Rust does have UB, but responsibility is isolated to unsafe blocks.

unsafe {
    let p = 1 as *const i32;
    let x = *p;   // UB possible
}

Isolating code in unsafe blocks means marking the entrance to the danger zone in the syntax.

In C/C++, landmines are scattered along ordinary paths, but Rust at least warns you, when you step out of safe code into unsafe territory, that you could lose a leg. Of course, once you open an unsafe block, you are responsible again.

4.2 Zig

Zig is a lower-level language that is more explicit than C. It surfaces overflow, alignment, optional values, and error handling at the language level. In debug/safe builds, integer overflow can be trapped, while ReleaseFast and ReleaseSmall builds turn runtime safety checks off, and illegal behavior such as overflow then becomes UB. Dangerous conversions such as @intCast, @alignCast, and @ptrCast are also made visible in the code. Because pointers, alignment, and unsafe operations remain, Zig is not a language where UB disappears entirely. And honestly, I don't know it that well either.

4.3 Go

Go favors defined behavior. Array and slice out-of-bounds accesses and nil dereferences typically result in a panic, and because Go has a GC, use-after-free and double-free do not occur in ordinary code. The unsafe package can be used to reopen C-style dangers.

arr := []int{1, 2, 3}
fmt.Println(arr[10])   // Panic, not UB

4.4 Java / C#

Most C-style UB is converted into runtime exceptions.

int[] arr = { 1, 2, 3 };
Console.WriteLine(arr[10]);   // IndexOutOfRangeException

int[] arr = {1, 2, 3};
System.out.println(arr[10]);   // ArrayIndexOutOfBoundsException

Out-of-bounds accesses throw exceptions, null references throw exceptions, memory deallocation is handled by the GC, and type mismatches are caught by runtime or compile-time checks. C# allows pointer usage via unsafe blocks, but the dangerous region is syntactically marked. Java also has Unsafe, JNI, and the Panama pathway, but these are separated from ordinary code.

unsafe {
    int* p = stackalloc int[10];
}

4.5 Swift / Kotlin

Nullability is encoded in the type system, which greatly reduces null pointer problems.

var name: String = "abc"
name = null            // compile error
var maybeName: String? = null

var name: String = "abc"
var maybeName: String? = nil

Array out-of-bounds accesses are handled as traps or exceptions, so failures are surfaced explicitly rather than silently corrupting state as UB would.

4.6 Python / JavaScript

C-style UB is largely absent. Instead, runtime errors and peculiar defined behaviors are common.

arr = [1, 2, 3]
arr[10]   # IndexError

const arr = [1, 2, 3];
console.log(arr[10]);   // undefined

JavaScript trades UB for a different kind of confusion: undefined, NaN, and implicit coercion. It does not have the compiler-assumes-this-is-impossible mode that collapses the entire meaning of a program.

4.7 Ada / SPARK

It provides range types, runtime checks, and a strong type system.

subtype Percent is Integer range 0 .. 100;

SPARK is a formally verifiable subset of Ada, focused on reducing overflow, out-of-bounds accesses, and data races through mathematical proofs and static analysis.

Ada is sometimes described as a more natural choice than C in safety-critical domains such as defense, aviation, and rail, but is there really a compelling reason to use Ada?

4.8 Explicitly Defined Behavior: C# checked / Java overflow

C# lets you choose between checked (exception on overflow) and unchecked (wraparound) for integer overflow, and whichever behavior you select is fully defined.

checked {
    int x = int.MaxValue;
    x = x + 1;   // OverflowException
}

Java's int overflow is also not UB; it is defined as two's complement wraparound.

int x = Integer.MAX_VALUE;
System.out.println(x + 1);   // Integer.MIN_VALUE

You can still introduce bugs, but this is not the kind of UB where the compiler assumes "no overflow occurs" and rewrites your code accordingly.

4.9 Comparison Table

4.10 Rice's Theorem and the "Universal Checker" Problem

When people ask about checking for UB, they usually think along these lines.

Can't the compiler or a static analyzer just find all UB ahead of time?

General UB detection runs into the same undecidability as the halting problem. For example, a question like "Does this program divide by zero on some input?" can directly encode whether an arbitrary program P terminates. If you can rephrase whether P halts as whether something divides by zero, then a universal checker that solves the latter immediately becomes a machine that solves the halting problem. It would be nice if such a machine existed, but unfortunately it does not.

Rice's Theorem generalizes this limitation from one problem to all semantic properties. It states that no algorithm can decide a non-trivial semantic property of computable functions in general.⁸In other words, it is not just division by zero that is blocked; most questions about what a program actually does hit the same wall. Concretely, these include the following.

• Is this pointer always valid at the point of execution?

• Does this integer addition overflow on any input?

• Is this array access in-bounds on every execution path?

• Do these two threads ever encounter a data race in actual execution?

• Does this function necessarily terminate on a given input?

Static analysis demands answers to these questions before execution. In the general case, it runs directly into the undecidability wall described above. The undecidability of the halting problem itself is a classical result shown in Turing's 1936 paper.⁹

Note that the limitation from Rice's theorem and the halting problem applies to arbitrary general programs as a whole. For Turing-complete programs where input size, loop counts, recursion depth, heap state, and thread interleavings are unbounded in principle, no universal checker can automatically decide every possible UB case.

Conversely, if the analysis target is narrowed enough,
for example, if the number of loop iterations is fixed, there is no recursion, memory regions and input ranges are finite, and every possible state of an embedded program or hardware model can be enumerated, then in principle every state can be explored.

In that case, model checking or exhaustive analysis becomes possible. Of course, the fact that the number of states is finite does not mean that the analysis cost is small. Even if the number of states is finite, if it is large enough, state explosion can still make the analysis very expensive in practice.

A common mistake many programmers make is to think, "Static analysis can always be made mathematically perfect."

But the correct conclusion is this:

"There is no general algorithm that can completely catch every UB case across general C/C++ programs as a whole. Therefore, practical tools must choose among false positives, false negatives, restricting the analysis target, or requiring annotations."

Among those, let us look at the options available to a static analyzer.

Options available to a static analyzer:

A universal UB detector cannot be expected from a general algorithm. Such a tool would be essentially equivalent to a "compiler that finds all bugs," and at that point it would be less a compiler and more a crystal ball.

This does not mean that theoretical limits cripple practical tools. Because no general solution exists, the approach is to carve out narrow, well-scoped problems and solve those.

• Sanitizers catch UB on the paths that actually execute.

• Static analyzers conservatively flag suspicious sites.

• Type systems prevent dangerous expressions from being written in the first place.

• Fuzzing feeds in inputs that humans would never think to try.

• Rules such as MISRA/CERT prohibit use of the dangerous subsets of C.

Rice's theorem explains "why, even after using multiple tools, a human still has to look at the end." C/C++ UB checking sits at the intersection of mathematical limits and practical cost, which is precisely why this problem is so persistently exhausting.

5. Practical Countermeasures

C/C++ continues to be used in performance-critical code, ABI layers, operating systems, embedded systems, game engines, drivers, and legacy codebases. As of 2026, the reality is closer to "enable your tools, establish coding rules, and mark danger zones" than to "just be careful."

• Sanitizers (ASan, UBSan, TSan)

• Static analyzers

• Fuzzers

• Maximizing compiler warnings

• MISRA / CERT rules

• Code review

• LLM-assisted UB auditing

• Documenting unsafe boundaries

For new C/C++ code, maintain at least one sanitizer build.

clang -Wall -Wextra -Wpedantic -Wconversion -Wshadow -fsanitize=undefined,address -fno-omit-frame-pointer main.c

gcc -Wall -Wextra -Wpedantic -Wconversion -Wshadow -fsanitize=undefined,address -fno-omit-frame-pointer main.c

UBSan is a tool for catching various UBs at runtime. The Clang documentation explains that UBSan inserts compile-time instrumentation to detect out-of-bounds accesses, invalid shifts, null/misaligned pointer dereferences, signed integer overflow, and more at runtime.¹⁰

Sanitizers are not proofs of correctness. Installing CCTV does not mean no thief exists; it only means you can see the thieves who happen to be caught on camera.

• Only paths that are actually executed get checked.

• Not all UB can be caught.

• The problems that surface may vary depending on optimization settings and build options.

• Runtime use may be restricted in kernel, embedded, or real-time environments.

• Do not assume that enabling sanitizers means production performance and behavior will be identical.

Example tool combinations:

Even when an LLM audit was applied to a codebase renowned for maturity and strict authorship (such as OpenBSD's find utility), UB candidates poured out, and Habets reports submitting a patch for an actual out-of-bounds write discovered in the process. LLM audits have their limits too. Confirming what they surface still requires a human expert. The work resembles housecleaning, except that picking up the broom means reading the standard document and the assembly side by side. Honestly, can anyone do all of this?¹

Summary:

C/C++ pushes failures into "undefined," while modern languages pull failures up into one of the following: compile error, runtime exception, unsafe boundary, or explicit wraparound.

UB can be thought of as the distance between "works on my machine" and "valid per the standard."

See Also

• cpp_idioms

• Programming Idioms

• C++ Memory Safety Debate

• Evolution of x86 Memory Management

References

C23 Standard sections cited in this post. The normative clauses behind the examples discussed.

• 6.3.2.3 (pointers, null pointer) - Misaligned pointers, comparison of NULL with objects and functions

• 6.3.1.4 (real floating to integer) - UB when float-to-int conversion is out of range

• 7.4 (character handling), 6.2.5 (char signedness, implementation-defined) - The isxdigit(char) problem

• 6.5.4.2 (Address and indirection operators)

Semantics of UB and the motivation for optimization. A supplementary perspective.

• Raph Levien: With Undefined Behavior, Anything is Possible - distinctions among the portable/semi-portable/standard C camps, and strict aliasing

• Paul J. Lucas: Undefined Behavior in C and C++ - the origin of "nasal demons" (John F. Woods, comp.std.c, 1992) and the disappearing-if case study

SEI CERT C Coding Standard.

• SEI CERT C Coding Standard - a collection of rules in C that lead to UB and security vulnerabilities

C++ Core Guidelines.

• C++ Core Guidelines - guidelines related to lifetime, bounds, type safety, and resource safety

What every compiler writer should know about programmers.

• M. Anton Ertl "What Every Compiler Writer Should Know about Programmers" - a paper examining the conflicts between UB in C and the tension between compiler optimizations and programmer expectations

cdrdv2-public.intel.com

Categories: Undefined Behavior | C++ Memory Safety Debate | Programming Idioms | WIKI