assert() and similar macros in SQLite
This document describes the assert() and similar debugging macros used in the SQLite source code, including assert(), ALWAYS(), NEVER(), testcase(), and conditional macros like SQLITE_COVERAGE_TEST. It explains their purpose in catching bugs during development and testing, and how they can be disabled for release builds.
Background
- The SQLite library (the most widely deployed database engine in the world, found in every smartphone, browser, and many apps) uses C-language **assert() macros** extensively for internal bug detection — a practice the article aims to explain and defend against criticism that these checks are "performance bugs."
- **assert()** is a C preprocessor macro that evaluates a condition and aborts (crashes) the program if it is false, but only in debug builds; in release builds it compiles to nothing. SQLite also defines custom macros like **neverCorrupt()** and **ALWAYS()** that behave differently from standard assert.
- The background debate: SQLite's developers deliberately leave many safety checks (bounds checks, null-pointer checks, state‑consistency checks) inside release builds via the `SQLITE_ENABLE_API_ARMOR` compile-time option — a design choice some outside critics consider a performance bug because the checks run in production.
- The article explains why SQLite's approach (keeping the checks, controlling them with fine-grained macros and compile-time flags) is deliberate engineering, not sloppiness: the library prioritizes stability and early failure over raw speed.