A companion to Rachel by the Bay’s earlier essay on the split between dead text files and living code — this one runs the problem in reverse. When a config file has to name an OS-defined magic value like O_NOATIME or TIOCM_RTS, the value arrives as a string, and something has to turn it into a number at runtime.
- In C this is trivial: include the header, use the symbol, resolved at compile time
- In a generic config-driven tool, a lookup table only covers symbols you knew about in advance
- Ask for O_SHINYTHING — a value the table doesn’t have — and the tool can’t express it
The standard fallback is a glorified eval: write a tiny temp.c that prints the value, compile it, run it, parse the output. It’s the same trick autoconf-generated configure scripts use — and it quietly depends on a compiler existing on the target system.
The essay’s real point is the asymmetry: data is dead and inspectable but can’t do anything; code is alive but only reachable by running it. Tools that sit on the boundary pay one of two taxes — a curated, incomplete vocabulary, or a runtime compile-and-execute hack. Neither is good, which is exactly why the gap is worth understanding.