Phase 2 — Memory & Pointers (M3)

This is the month that separates C dabblers from people who actually write C. You already survived syntax and toolchains in M1-M2; now you’re going to internalize the machine’s memory model until you can sketch it on a whiteboard for anyone asking. The stakes are real — every segfault in your future, every memory leak in a 3AM incident, every SIMD kernel you’ll write in Phase 6 traces back to whether the map in your head matches the map in the CPU.

The M3 Target

By July 31, 2026 you can:

  1. Draw the memory diagram of any C program on a whiteboard — stack, heap, BSS, text, rodata, mmap regions — and correctly place every variable declared in the source.

  2. Explain ownership for every malloc in code you write — who allocates, who frees, and what convention the function signature implies.

  3. Diagnose the seven canonical memory bugs (heap overflow, use-after-free, double-free, leak, uninitialized read, stack overflow, alignment fault) both by symptom and by tool output (ASan, valgrind, gdb).

  4. Write a working arena allocator in one sitting — bump + reset semantics, alignment-aware, roughly 100 lines. Ryan Fleury / Chris Wellons style.

  5. Read gnarly declarations like int (*(*fp)(int))[3] without cdecl.org — though you’ll still use cdecl.org because that’s not a weakness.

What Most People Skip and Regret

Ownership convention. Everyone learns malloc/free. Almost nobody sits down and decides, “in this codebase, functions that return a T* transfer ownership; functions that take a const T* borrow it.” Leaks in real C code are almost never accidental — they are the residue of an unclear ownership story. You’re going to fix that in yourself this month.

File Order

#

File

Why

1

01_stack_heap_bss_text.md

The map. Everything else references this.

2

02_pointer_arithmetic.md

Why p+1 doesn’t mean “next byte”.

3

03_malloc_free_lifecycles.md

The API and its footguns.

4

04_ownership_and_lifetimes.md

The convention that saves you.

5

05_memory_bug_taxonomy.md

The seven bugs you’ll meet in production.

6

06_custom_allocators.md

Arena, pool, freelist — the modern C style.

7

07_pointer_wizardry.md

Function pointers and hairy declarations.

8

projects.md

Two deliverables that prove you got it.

Exit Criteria (self-check, be honest)

You are done with M3 when all of the following are true. Not “mostly.” All.

  • You can start with a blank whiteboard and, given the C source of a 40-line program with globals, static locals, malloc, and a recursive function, draw the memory layout correctly in under 5 minutes.

  • ulimit -s — you know what it returns on your Mac (8176 KB = ~8 MB default on macOS/Linux) and why declaring int arr[<phone_number_or_numberic_id_or_random_id_23>] inside main segfaults.

  • You’ve shipped both projects in projects.md, and your arena allocator passes an ASan test suite with zero ERROR: AddressSanitizer messages.

  • You can explain to a friend why realloc in a loop is almost always a bug, and what to do instead.

  • You’ve read Chris Wellons’ Arena allocator tips and tricks at least twice — once for the mechanics, once for the philosophy.

  • You have a personal “ownership cheatsheet” in this folder documenting the convention you’ll use for the rest of the year (returns-owned vs. borrows-const-pointer vs. out-parameter-fills).

The Reading List (canonical)

Next: 01_stack_heap_bss_text.md