Retrofitting spatial safety to lines of C++

Original Article ↗ Hacker News Discussion ↗

Google’s move to enable “spatial memory safety” in libc++—adding bounds checks to standard containers in production—highlights how many real-world C++ bugs and exploits stem from out-of-bounds access, and how cheaply many of them can now be caught at runtime. Commenters contrast spatial vs temporal memory safety, argue over why C and C++ still default to unsafe behavior despite decades of safer languages, and debate whether opt‑in hardening (via spans, compiler flags, or debug modes) is an adequate answer compared to making safety the default.

Terminology: Spatial vs Temporal Memory Safety

  • Several comments clarify that “spatial memory safety” is long-standing security/PL jargon for out-of-bounds access, contrasted with “temporal memory safety” (use-after-free, lifetime issues).
  • Some C++ programmers say they’ve never heard the term; security and PL folks say it’s been standard in their circles for 10+ years.
  • The terminology is increasingly used in C++–Rust discussions to separate bounds issues from lifetime issues.

How Big a Problem Is Memory Safety?

  • One side stresses industry data: historically ~70% of vulnerabilities in systems like Android were memory-safety related, dropping sharply as more memory-safe languages are adopted.
  • Another side argues that OWASP’s top web vulnerabilities are not memory-safety-related and claims Rust advocates overstate memory safety as the dominant security problem.
  • Counterargument: web apps don’t use C++ much precisely to avoid memory-safety risks; memory safety is still a massive, distinct bug class and is widely recognized by major security organizations.

Bounds Checking and C++ (std::span, gsl::span, flags)

  • Strong support for bounds checking as a big practical win; D added it ~20 years ago, game engines and alternative C++ libraries (EASTL, Unreal) commonly use checked containers.
  • Debate over std::span:
    • It’s not bounds-checked by default per the C++ standard.
    • Some implementations (libc++ hardening, debug modes) can enable checks via non-portable flags; gsl::span is cited as always-checked.
    • Critics say “unsafe by default + toolchain flags” is insufficient; defenders argue it’s analogous to enabling optimizations.
  • There’s frustration that enabling bounds checks in C++ is harder and less standardized than flipping a single “build type” switch.

C++ Standards, Safety, and Compatibility

  • Some argue the C++ committee has historically prioritized backward compatibility and performance over safety, leading to “wrong defaults” like unchecked standard containers.
  • Safety advocates want “safe by default, opt-in to unsafe”; others say memory safety should be one of many bug classes handled via tests, analysis, and disciplined coding.

Libc++ Hardening in Production

  • Google’s hardened libc++ mode is described as newly practical for production, with low average overhead (~0.3%).
  • Enabling it in production, not just tests/debug, reportedly exposed many previously undetected spatial bugs.