Undefined Behavior Deep Dive

"Undefined behavior" has appeared in nearly every chapter of this course. This one finally defines it precisely, explains the genuinely counter-intuitive reason it's dangerous, and catalogs every instance flagged so far in one place.

What "Undefined Behavior" Actually Means

The C standard defines three genuinely different categories, and conflating them is a real, common mistake:

• Unspecified behavior — the standard allows several possible results; the implementation picks one, but doesn't have to document which
• Implementation-defined behavior — unspecified, but the implementation must document its choice consistently (c3-1's bit-field ordering is exactly this)
• Undefined behavior — the standard imposes literally no requirements at all. Anything is a conforming result — including things that look nonsensical, like appearing to work perfectly, or genuinely misbehaving in a way that has nothing obviously to do with the actual bug

Why the Compiler Is Allowed to Assume UB Never Happens

This is the real, counter-intuitive payoff. Compilers don't merely fail to detect UB — they actively use its absence as a proven fact during optimization. If code contains a signed overflow, the compiler is standard-sanctioned in assuming it never actually occurs, and can eliminate branches or checks that logically depended on that "impossible" case — producing results that look like a compiler bug, but are the compiler correctly exploiting a guarantee the standard itself grants it. The C community's own phrase for the theoretical extreme of this is that UB could licitly make "demons fly out of your nose" — a real, standard-permitted outcome, however absurd it sounds.

A Consolidated Catalog, By Chapter

• Signed integer overflow — c1-2
• Out-of-bounds array access — c1-6
• Dereferencing NULL or a dangling pointer — c1-7
• Buffer overflow via strcpy — c1-8
• Use-after-free, double-free — c2-2, c2-3
• Reading the "wrong" union member — c2-1, in most cases
• Excessive or negative shifts — c3-1
• An unprotected data race — c3-3

Signed Overflow, Revisited With the Real Mechanism

The programmer intended this loop to terminate once i overflows. But since signed overflow is UB, the compiler is entitled to assume i + 1 > i is always true — overflow "can't happen" — and may optimize this into a genuine infinite loop, silently removing the termination condition the programmer relied on. This is a real, documented class of surprising optimizer behavior, not a hypothetical.

Strict Aliasing

A new rule: the compiler assumes two pointers of different, unrelated types never point at the same memory (with narrow exceptions like char *). Reinterpreting a float * as an int * and dereferencing it violates this — undefined behavior — and permits the compiler to reorder or cache reads through such pointers in ways that produce genuinely wrong results if the assumption turns out to be false. c2-1's union type-punning gotcha is closely related: a union is one of the narrow, standard-sanctioned ways to reinterpret bits in some cases — a raw pointer cast between unrelated types is not, and violates strict aliasing outright.

Rust's Answer

Rust's entire type system and borrow checker exist substantially to make every category on this chapter's own catalog structurally impossible to write in safe code — not detected as a separate check layered on top, but literally inexpressible. rust3-2's own unsafe blocks are the deliberate, opt-in escape hatch — the one place a Rust programmer takes on exactly the same responsibility C always has, by choice, in a clearly marked and narrow scope.

Coding Challenges