Version 2 (2026-07-19): adds a second contribution (pointer-arithmetic bypass of ReleaseSafe via *T reads and writes and @ptrCast), instruction-level root-cause disassembly, and robustness evidence across three environments (Linux ELF, native Windows PE, emulated aarch64), three Zig versions, and four build modes. Resolves the v1 run-count/provenance accounting and corrects a citation scope. Core results unchanged. Out-of-bounds writes (CWE-787) and out-of-bounds reads (CWE-125) are among the most common and damaging weaknesses tracked by MITRE, and they remain a leading source of critical vulnerabilities in systems software. Zig is a recent systems language that keeps C-style manual memory management but adds runtime safety checks whose presence depends on the build mode: the Debug and ReleaseSafe modes insert bounds checks, while ReleaseFast and ReleaseSmall omit them. This paper measures what that choice means in practice. We write four small Zig programs (an out-of-bounds read that leaks a secret, an out-of-bounds write that corrupts an adjacent flag, an out-of-bounds write that hijacks control flow, and a many-item-pointer read that sidesteps the checks altogether) and run each under all four build modes. The same source code panics safely in the checked modes and becomes a working exploit primitive in the unchecked ones; the outcome depends only on the optimisation flag. The fourth program is the exception, leaking the secret in every mode because the pointer type it uses carries no length to check. We explain why this happens, discuss what it means for shipping Zig code, and give practical recommendations for developers.
Sadik Erisen (Sun,) studied this question.
Synapse has enriched 5 closely related papers on similar clinical questions. Consider them for comparative context: