C Must Die

C’s rise is inseparable from Unix’s early need to move across hardware, but its modern “portability” bargain comes with a darker catch: undefined behavior gives compilers permission to break code in ways that vary by optimization level, compiler version, architecture, and even the order of internal passes. That combination—portable syntax paired with non-portable semantics—turns C into a language where “it works on my machine” can become a security risk, not just a debugging headache.

The story begins at Bell Labs, where Ken Thompson and Dennis Ritchie built early Unix tooling for PDP systems using assembly because writing machine code was too labor-intensive. C emerged as a replacement that let Unix kernels and utilities be rewritten with low-level control while avoiding per-architecture rewrites. Porting Unix to new hardware then became easier, since C source could be recompiled rather than manually reassembled for each instruction set.

But as Unix spread, performance and correctness problems appeared. C programs often ran slower than expected when the target hardware diverged from the original PDP environment. Compiler developers responded with increasingly aggressive optimizations, which gradually moved C further from “transparent” low-level behavior. The language standardization effort—culminating in the 1989 C standard (often referred to as C89)—tried to formalize portability using an “abstract machine.” That abstract machine made it possible to write programs that behave consistently across platforms, while still letting compilers optimize.

The mechanism that enables both portability and optimization is undefined behavior. When a program uses constructs the standard doesn’t define—such as shifting by too many bits, dereferencing invalid pointers, relying on signed overflow, or violating strict aliasing rules—the standard imposes no requirements. Compilers can treat such code as impossible, ignore it, reorder logic, or generate different results across builds. A concrete example shows a left shift that seems like it should yield a predictable value; instead, the outcome depends on how the compiler reasons about the undefined case. Another example demonstrates null-pointer checks being optimized away because the compiler can assume the “impossible” dereference never occurs, changing control flow.

The transcript then broadens the consequences: undefined behavior can linger silently until a change in compiler, flags, or architecture triggers a failure. It can also undermine security practices. Clearing sensitive data with memset may be removed if the compiler decides the memory is no longer used, leaving passwords or secrets in registers or stack memory. Strict aliasing further complicates low-level programming by allowing compilers to assume differently typed pointers don’t refer to the same memory—an assumption that breaks common “type punning” tricks.

A major flashpoint is signed integer overflow. In the C standard, signed overflow is undefined behavior, so compilers may delete overflow checks entirely. The transcript recounts a long-running GCC controversy where a developer’s overflow assertion disappeared under certain conditions, prompting debate over whether compilers should prioritize standards-based optimization or preserve safety checks for existing code. The broader conclusion is blunt: C’s combination of low-level power and undefined behavior makes it unreliable as a general development tool, pushing programmers toward languages like Rust or Zig that aim to reduce or eliminate these “time-bomb” failure modes.