How (memory) safe is Zig? (2021)

Summary

I keep seeing discussions that equate zig's level of memory safety with c (or occasionally with rust!). Neither is particularly accurate. This is an attempt at a more detailed breakdown. This article is limited to memory safety. See Assorted thoughts on zig and rust for a more general comparison. I'm concerned mostly with security. In practice, it doesn't seem that any level of testing is sufficient to prevent vulnerabilities due to memory safety in large programs. So I'm not covering tools like AddressSanitizer that are intended for testing and are not recommended for production use. Instead I'll focus on tools which can systematically rule out errors (eg compiler-inserted bounds checks completely prevent out-of-bounds heap read/write). I'm also focusing on software as it is typically shipped, ignoring eg bounds checking compilers like tcc or quarantining allocators like hardened_malloc which are rarely used because of the performance overhead. Finally, note the 'Updated' date below the title. Zig in particular is still under rapid development and will likely change faster than this article updates. (See the tracking issue for safety mechanisms). I see two major categories of safety mechanisms: Adhoc runtime checks. These appear in all zig and rust codebases but are very rare in idomatic c. Many of these checks are also idiomatic in modern c++ codebases but are hamstrung by backwards-compatible interfaces. These checks are easy to implement and probably sufficiently non-controversial that any new systems language will have similar features. Examples include: Pervasive use of a slice type (pointer + length) and bounds-checking reads/writes of those slices. Disallowing null pointers, except via an 'optional' type which cannot be derefenced without checking for null. Builtin support for tagged unions which cannot be accessed without checking the tag. Automatic checking of over/underflow in arithmetic and when casting between numeric types. Using a separate type for nu...