Language FoundationsC Programming Deep DiveMedium

Explore Undefined Behavior

Master the fundamental concepts of c programming deep dive through this focused micro-challenge.

~45 minutes C Programming Deep Dive Ready to learn

Topic Overview

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

bash
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.

Implementation Task

Your Task

Demonstrate four classic kinds of undefined behaviour in C without invoking any of them. Each demo sets up the dangerous situation, then shows the check that prevents it:

signed overflow;
an out-of-bounds read;
use after free;
double free.

Input

One word: overflow, bounds, uaf or double. Anything else (or empty input) runs the full report.

Output

overflow: print === Signed Overflow ===, INT_MAX = 2147483647, x + 1 would be UB in C; use checked arithmetic instead, then overflow would occur — refused (the check x < INT_MAX fails).
bounds: print === Out of Bounds Access ===, array length = 5, requested index = 5, then bounds check rejected access.
uaf: malloc an int, free it and set the pointer to NULL. Print === Use After Free ===, pointer nulled after free, then use-after-free prevented.
double: malloc, free, and set to NULL. Print === Double Free ===, then second free skipped (already NULL).
full report: all four demos in that order, then Compile with sanitizers to detect UB: and gcc -fsanitize=undefined,address -g prog.c (two leading spaces).

The dash in "would occur — refused" is an em dash (U+2014).

Example

Input:

c
Loading…

Output:

c
Loading…

Requirements

Never execute the undefined operation itself. Guard it with the check.
Set pointers to NULL after free. That is what makes the later checks possible.

Hidden tests cover the bounds, use-after-free and double-free demos, and the full report.