C++ and Safety
summary
Governments and agencies (NSA, NIST, White House) push away from memory-unsafe languages after studies that find about 70% of vulnerabilities trace to memory bugs. C++ lacks mandatory protections: compilers, sanitizers and static analysers (e.g. AddressSanitizer and static analysers) catch many issues but can’t eliminate undefined behavior without breaking performance or compatibility. Lifetime safety has three practical approaches—GC, runtime checking (ASan), or static borrow checking like Rust's borrow checker—and the core claim is C++ cannot be made fully memory‑safe without becoming a different language.
AI-written summary · about
chapters (15)
- 0:00Introduction and motivation
- 1:07Safety vs security vs correctness
- 5:59Language safety in C++
- 15:07Government push for memory safety
- 22:30Undefined behavior in C++
- 24:14Type safety issues
- 27:26Bounds safety challenges
- 32:02Lifetime safety problems
- 39:27Initialization safety concerns
- 44:06Thread safety risks
- 47:36Arithmetic safety pitfalls
- 49:23Definition safety issues
- 51:09Can C++ ever be safe?
- 57:49Survey on undefined behavior impact
- 1:00:59Future of C++ and safety
related talks
45mThe existential threat against C++ and where to go from here
01h 28mKeynote: Safety, Security, Safety and C / C++ - C++ Evolution
14mEmbedded C and C++: A Security Perspective
43mC++ and Security: Can We Do Better?
54mKeynote: Safety in C++: All the Safeties!
43mEverything I learned about static analysis and program safety in C++
26mUndefined Behavior in 2017 (part 2 of 2)
57mThe Real Problem of C++