Memory Safety for Skeptics

Memory safety vs. other vulnerabilities

• Several comments stress that many real-world security problems are logic bugs or human‑centric (social engineering), not memory corruption.
• Others counter that memory bugs are uniquely dangerous: they can stay latent for years, be hard to reproduce, and break isolation between components.
• A subthread argues that logic bugs usually have localized, understandable behavior, whereas memory-unsafe behavior can “time travel”, invalidate reasoning about the whole program, and is much harder to exhaustively rule out.

Definitions and scope of “memory safety”

• Strong disagreement over what “memory safety” should mean:
  • Some align with Hicks’ view that it should be defined rigorously (e.g., via pointer capabilities) rather than as an ad‑hoc list of forbidden errors.
  • Others treat it more pragmatically: “no memory-corruption vulnerabilities,” including GC’d languages like Java/Go.
• Debate over whether memory safety must be enforced statically, or whether languages that rely heavily on runtime checks (Java, Rust bounds checks) still count.
• Another angle defines safety as the absence of untrapped/undefined behavior.

Rust, C/C++, and “95% safe” compromises

• Multiple commenters reject the idea that memory-safety skepticism is a strawman, citing prominent C++ figures advocating “95% safety” as good enough. Critics ask how one measures 95% and note attackers will aim at the remaining 5%.
• Pro‑C++ voices argue for “getting good,” using tooling, and possibly relying on future hardware checks, instead of rewrites to Rust. Counterarguments point out that even top C++ engineers regularly ship memory bugs and that static guarantees greatly ease reasoning and maintenance.
• Rust’s unsafe blocks are highlighted: Rust is not magically safe overall; unsound unsafe code and compiler soundness bugs exist. Still, safe Rust is seen as a major structural improvement over C/C++.

Other languages and systems programming

• Ada/SPARK are cited as earlier memory-safe(-ish) systems languages with formal-methods tooling but limited mainstream adoption.
• Go and Swift are noted as not fully memory safe (e.g., data races in Go are UB), though still much safer than C/C++.
• Zig’s popularity is taken by some as evidence that many developers still don’t treat memory safety as a baseline requirement.

Static, dynamic, and hardware-based protections

• Some emphasize sanitizers, fuzzers, and proof assistants (Typed Assembly Language, DTAL, Miri) as practical tools short of full static guarantees.
• Hardware memory-safety features (e.g., tagged memory) are mentioned; one side sees them as a reason to modernize C/C++ in place, another as raising the bar and making unsafe code harder to keep working.

Null pointers, UB, and exploitability

• Lively debate on whether null-pointer dereferences are “memory safety” issues:
  • One side notes they rarely lead to exploits and are mostly crashes.
  • Others point out that, since dereferencing null is UB in C/C++, compilers can assume it never happens, optimize away checks, and thereby create subtle vulnerabilities.
• More generally, some argue UB is “worse” than ordinary memory bugs because it voids any semantic guarantees and defeats higher-level safety reasoning.

Thread safety and concurrency

• Several comments note that Rust’s aliasing and ownership rules also enforce key aspects of thread safety, whereas C/C++ and Go can have data races that break memory guarantees.
• Some claim thread safety is actually more important in practice than memory safety; others respond that Rust’s model addresses both together.

Metrics, tradeoffs, and costs

• Questioning of the commonly-cited “~70% of vulnerabilities are memory-safety related”; calls to distinguish spatial vs temporal errors.
• Concern that strong static checks may hurt compile times and development velocity for large codebases, and that articles underplay these tradeoffs.

Policy, incentives, and liability

• One commenter suggests shifting from technical evangelism to legal/organizational incentives: hold companies liable when avoidable memory-unsafe software leads to breaches, making safe languages the default business choice.