AI
Why Governments Started Caring About C++ Memory Safety
CrowdStrike’s 2024 update bricked eight million machines. The kernel-level bug came from a cybersecurity product, which made the outage visible to everyone. Multiple governments had already published the underlying indictment two years earlier: 70% of CVEs across the industry trace to memory unsafety in C and C++. The number has held steady for years and across vendors. Regulators drew the line. Companies without a concrete plan for memory safety would no longer qualify for government contracts. That’s the pressure Engert opens with, and it’s what drove C++26’s safety work.
Safety and Security Are Different Problems
Memory safety and functional safety are not the same problem. A buffer overread on a data-center server lets an attacker extract stored secrets. Functional safety, the kind governing a robotic arm that moves steel billets in a train depot, protects people from machinery and machinery from people. Both are system properties. You cannot fix either by patching one function in isolation; the entire system has to be considered. Engert marks each concern with a different icon throughout the talk to track where each C++26 change applies.
Undefined Behavior and Erroneous Behavior
Engert steps through a short program. Two variables defined at namespace scope get zero-initialized implicitly. Move them into function scope, and GCC fires a warning: uninitialized read. For 25 years the standard called that undefined behavior, which gave compilers license to optimize around it, including deleting null-pointer checks they deemed unreachable.
“erroneous behavior changes the entire world in a sense.” — Daniela Engert
C++23 renamed it erroneous behavior. The distinction matters because erroneous behavior is fully defined. A modern compiler recompiling old code now inserts implicit initialization instead of treating the bad path as dead code.
Constant Evaluation as a Compile-Time Safety Net
C++ compilers have been language interpreters since C++11. When code runs through constant evaluation (constexpr, static_assert, constinit), the compiler executes it inside a virtual machine and must flag every undefined behavior it finds. Address sanitizers, UB sanitizers, and memory sanitizers each catch a slice of that at test time. Constant evaluation runs all of them at once on every build. C++26 expands constant evaluation coverage substantially; the remaining gaps (I/O, multithreading) are now the short list. Old code gains this protection for free on recompile.
Standard Library Hardening and Contracts in C++26
Standard library hardening, already in most modern compilers and formally landing in C++26, adds precondition checks inside container functions like span. Without it, an out-of-bounds subscript returns garbage values and the program exits reporting success. With the hardened vs unhardened span out-of-bounds demo (27:21), execution stops at the first bad access. Proposal P2900 adds contracts, pre and postcondition annotations on function declarations enforced at runtime with full optimization on.
“It’s about contracts for C++.” — Daniela Engert
The violation handler can log and continue (observe semantics) or terminate after logging (enforce semantics), covering both security and functional safety use cases.
Notable Quotes
erroneous behavior changes the entire world in a sense. Daniela Engert · ▶ 12:02
Use contemporary C++. Use strong types. Daniela Engert · ▶ 23:25
It’s about contracts for C++. Daniela Engert · ▶ 28:18
Key Takeaways
- C++23 reclassified uninitialized reads as erroneous behavior, letting compilers insert implicit initialization instead of exploiting the gap.
- Constant evaluation runs code through the compiler’s built-in interpreter at build time, catching all undefined behavior that sanitizers only find at test time.
- C++26 ships two runtime defenses: standard library hardening that halts execution on invalid container access, and P2900 contracts for pre/postcondition enforcement.