🧬 Types & Qualifiers, In Depth

Undefined behavior: here be nasal demons

⏱ 16 min · free interactive lesson · quizzes, visualizations & a real compiler

The C standard defines what programs mean — but for certain operations it deliberately says: nothing. "Undefined behavior: behavior, upon use of a nonportable or erroneous program construct, for which this document imposes no requirements." No requirements. Your program may crash, print 42, silently corrupt a file, or appear to work perfectly for ten years and fail during the demo.

The right mental model: a contract

Think of the standard as a contract between you and the compiler. You promise your program never executes UB; in exchange, the compiler generates blazingly fast code that only has to be correct for programs that keep the promise. UB isn't "an error the compiler catches" — it's a case the compiler is allowed to assume never happens and optimize accordingly. That assumption is where the shocking stories come from.

Exhibit A: the vanishing NULL check

int get(int *p) {
    int v = *p;          /* deref first...                     */
    if (p == NULL)       /* ...check later. Compiler: "p was   */
        return -1;       /*  dereferenced, so it can't be NULL
                            here" — branch DELETED at -O2      */
    return v;
}

Read line 2: p is dereferenced. The compiler reasons: "if p were NULL, line 2 would be UB, and UB never happens — therefore p isn't NULL — therefore the if on line 3 is dead code." The safety check is deleted. This exact pattern (dereference above a check) caused a famous Linux kernel vulnerability in 2009: the compiler removed a NULL check and turned a bug into an exploit.

Exhibit B: one program, two answers

#include <stdio.h>

int wraps(int x) {
    return x + 1 < x;    /* "detect overflow"... via overflow  */
}

int main(void) {
    printf("%d\n", wraps(2147483647));   /* INT_MAX */
    return 0;
}

$ gcc -O0 wraps.c && ./a.out
1
$ gcc -O2 wraps.c && ./a.out
0
# same source, both "correct": the program's meaning was undefined

Since signed overflow is UB, the compiler may assume x + 1 never wraps — so x + 1 < x is simply false, at compile time, for all x. At -O0 the wrap physically happens and you see 1. Neither answer is "wrong": a program that executes UB has no defined answer at all.

The classics gallery

▶ This spot has an interactive memgrid widget — open the interactive lesson to play with it.

Why does UB exist at all?

It's not sadism — it's the price of C's two core promises:

• Performance: checking every array index, every pointer, every add for validity would cost cycles on every operation. UB says: no mandatory checks — programs pay only for what they use. It also licenses big optimizations: assuming i++ never wraps is what lets loops vectorize.
• Portability (of the language, across weird machines): C runs on hardware that traps on overflow, on machines where NULL isn't bit-pattern zero. By defining nothing, the standard lets each platform do what's natural and fast there.

Your defense kit

#include <stdio.h>
#include <stdlib.h>

int main(void) {
    int a[3] = { 1, 2, 3 };
    int sum = 0;
    for (int i = 0; i <= 3; i++)    /* off by one! */
        sum += a[i];
    printf("%d\n", sum);

    int *p = malloc(sizeof *p);
    free(p);
    *p = 5;                          /* use after free! */
    return 0;
}

$ gcc -g -fsanitize=address,undefined buggy.c && ./a.out
buggy.c:8:16: runtime error: index 3 out of bounds for type 'int [3]'
=================================================================
==4242==ERROR: AddressSanitizer: heap-use-after-free on address
    0x602000000010 ... WRITE of size 4 at buggy.c:13
    freed by thread T0 here: #1 main buggy.c:12
# file and line of the bug AND of the free — debugging on easy mode

• Always: -Wall -Wextra (and treat warnings as errors with -Werror in CI). Free, instant, catches whole bug classes.
• During development: -fsanitize=address,undefined — ASan catches out-of-bounds and use-after-free at the moment they happen; UBSan pinpoints overflow, bad shifts, misaligned access with file:line precision.
• Occasionally: Valgrind (no recompile needed), and -O2 vs -O0 behavior differences as a smoke alarm: if optimization "breaks" your program, suspect UB in your code first, not a compiler bug.

▶ This spot has an interactive editor widget — open the interactive lesson to play with it.

You now hold the full type system — every qualifier, every keyword, every trapdoor. Next stop, Part 4: the layer that rewrites your code before the compiler even sees it — the preprocessor.