Part VI — Open-source package walkthroughs

This Part takes every concept from Parts I–V and points at where it lives in real, widely-deployed C codebases. The goal is to make reading unfamiliar C — the actual day-to-day skill of an experienced C engineer — feel approachable. Snippets here are simplified/paraphrased to teach the design, not copy-pasted verbatim; read the linked real files for the authoritative current source.

33. SQLite: the amalgamation, the VFS layer, opcode-based execution

What it is: the most widely deployed database engine in the world (every Android/iOS app, every browser, git, Python's stdlib all embed it) — a single C library, no server process, one file on disk.

Concept mapping:

The amalgamation (sqlite3.c, ~250K lines generated from the real multi-file source tree) is Section 13's multi-file build taken to its logical extreme in reverse: SQLite ships as one giant translation unit specifically so the compiler can inline and optimize across what would otherwise be file boundaries — a deliberate trade of Section 13's modularity for whole-program optimization, appropriate because SQLite is a leaf dependency, not code you edit daily.
The VFS (virtual file system) layer is Section 11.2's function- pointer-table pattern, at the center of SQLite's entire portability story: every OS interaction (open, read, write, lock) goes through a struct of function pointers (sqlite3_vfs), so porting SQLite to a new OS means implementing one struct, not touching the other 250K lines:

// simplified sketch of SQLite's real sqlite3_io_methods design
typedef struct sqlite3_io_methods {
    int (*xRead)(void *file, void *buf, int amt, long long offset);
    int (*xWrite)(void *file, const void *buf, int amt, long long offset);
    int (*xSync)(void *file, int flags);
    int (*xLock)(void *file, int lockType);
    int (*xUnlock)(void *file, int lockType);
    // ... this table IS the abstraction boundary between SQLite and any given OS
} sqlite3_io_methods;

SQL execution as a bytecode VM: SQLite compiles SQL text into an opcode sequence (visible via EXPLAIN) and runs it on a small virtual machine — the same architecture as Section 22.2's _Generic dispatch generalized into a real interpreter loop (a giant switch over opcode values, each case implementing one instruction), and the same idea behind CPython's bytecode interpreter, just written in C instead of being one.
Ownership convention: sqlite3_open()/sqlite3_close(), sqlite3_prepare_v2()/sqlite3_finalize() — Section 10.3's _new/ _free pairing, applied consistently across SQLite's entire public API, is why every SQLite tutorial's first lesson is "always call sqlite3_close."

# Try it yourself:
sqlite3 :memory: "EXPLAIN SELECT 1;"   # see the actual opcodes for a trivial query