Explore Undefined Behavior

The Compiler Assumes You Never Trigger UB

Undefined behavior means the C standard places no requirements on what happens next. Clang and GCC treat that as a license to optimize aggressively: a null check after a dereference may disappear because the compiler reasons the dereference could not have happened if the pointer were null. The Linux kernel's famous null-check elision bug came from exactly this assumption.

Common Traps You Will Demonstrate

• Signed overflow: INT_MAX + 1 on a signed int is UB; unsigned wraps by definition
• Out-of-bounds: arr[5] on int arr[5] reads past the object; ASan catches it instantly
• Use-after-free / double-free: heap metadata corruption, classic exploit primitive
• Uninitialized reads: stack garbage becomes "works on my machine" nondeterminism
• Null dereference: immediate fault on Linux, or worse, optimizer surprises

bashCopy
Loading…

UBSan and ASan turn silent UB into loud crashes during development.

For this exercise, you will document six UB categories with commented-out dangerous lines and safe alternatives. This task asks you to explain each case in prose, because every serious C codebase runs sanitizers in CI and engineers still ship UB without understanding why the optimizer "broke" their check.