Phase 0 — Refresher & Toolchain (Month 1: July 2026)¶

You’ve written C in college. You’ve probably not written it seriously in two years. That’s fine — muscle memory returns fast if you rebuild the tools around the language first. This month is not about writing clever code. It is about being able to write, compile, debug, and inspect C without friction, because every downstream phase (kernels, threading, SIMD) assumes you can already do this in your sleep.

The pitch you’re aiming at by M13 — “I write C that ships in production, from SIMD kernels to multi-threaded services, and I can debug someone else’s segfault at 2 AM without flinching” — starts here with the boring stuff. Compilers, flags, make, gdb, lldb. If you skip this, you will spend M4-M13 fighting your environment instead of fighting the problem.

M1 Target¶

By the end of July 2026 you should be able to, from a cold terminal, in under 60 seconds:

Write a multi-file C program with a header, compile it with -Wall -Wextra -Wpedantic -Werror -g -fsanitize=address,undefined, and get zero warnings.
Run it under lldb (macOS) or gdb (Linux), set a breakpoint, step, print a struct member, and continue.
Take a deliberate segfault, reproduce it, and get a stack trace with ASan telling you the exact line and read/write kind.
Explain out loud, without notes, what .i, .s, .o, and the final executable each contain and how -E, -S, -c produce them.

Exit Criteria (all must be true)¶

hello.c → hello in a Makefile, make clean && make works, make alone is idempotent.
A 3-file mini-project (main.c, utils.c, utils.h) with header guards, compiled with the strict flag set above.
Reproduce 5 classic segfaults (null deref, use-after-free, stack overflow via infinite recursion, out-of-bounds write, double free) and produce ASan/UBSan output for each — writeup in projects/segfault_zoo/.
compile_commands.json present in your project root, clangd gives you go-to-definition in your editor.
You can name the top 15 gdb/lldb commands from memory (b, r, n, s, c, bt, p, x, frame, up/down, finish, watch, info args/locals, disassemble, si).

What Most People Get Wrong About Phase 0¶

They treat toolchain setup as a one-time chore, breeze through with -O0 and no warnings enabled, and then spend six months learning C with the compiler actively hiding bugs from them. Then when a segfault hits in a real project, they printf-debug for two hours because they never internalized gdb. The r/C_Programming consensus in the last two years is blunt: turn on -Wall -Wextra -Wpedantic -fsanitize=address,undefined on day one and treat every warning as a compiler error. If you do this, roughly 60-70% of the classic C footguns (uninitialized reads, buffer overflows, use-after-free) get caught by tooling before they teach you a painful lesson at 2 AM. This is the single highest-leverage habit in the entire 13-month plan.

Corollary: printf-debugging is fine as a first pass — it’s fast — but if you find yourself doing it for more than five minutes, you have skipped a gdb/lldb skill you need to build now.

Files in This Phase¶

#	File	What it covers
1	01_compiler_toolchain.md	gcc vs clang, the flag set, sanitizers, `-E -S -c` inspection
2	02_build_systems.md	Make from first principles, then CMake and ninja
3	03_debugging_stack.md	gdb top-20, lldb equivalents, valgrind vs ASan on Apple Silicon, rr
4	04_the_first_week_reset.md	7-day muscle-memory plan
5	05_editor_setup.md	neovim/vscode + clangd + compile_commands.json
6	projects.md	Two deliverables with acceptance criteria

Time Budget (10-15 h/week × 4 weeks = 40-60 h)¶

Week 1: Compiler + flags + first hello (8-12 h) → file 01 + file 04 days 1-3
Week 2: Make/CMake + first multi-file lib (10-15 h) → file 02 + project 1
Week 3: gdb/lldb + segfault zoo (10-15 h) → file 03 + project 2
Week 4: Editor polish, clangd wired up, buffer week (8-12 h) → file 05

Do not extend Phase 0 past 5 weeks. If you’re still fiddling with your .vimrc in week 6, you’ve lost the plot. Ship it and move to Phase 1.

Next: 01_compiler_toolchain.md