Keynote: Safety in C++: All the Safeties!
summary
Argues memory safety needs clearer definitions, cites an NSA finding that 70% of vulnerabilities trace to memory issues, and points to SBOM and EU/US rules shifting vendor liability. Explains the frame rule and non‑interference as the real containment goal, shows undefined behavior breaks all guarantees — undefined behavior invalidates all properties — and recommends sanitizers plus fuzzing. Demonstrates a working experiment where a formal verifier (Daphne) fails to prove a loop invariant until augmented by an LLM hint, credited as Daphne + Bing chat solving the proof.
AI-written summary · about
chapters (25)
- 0:00Intro
- 1:14Memory Safety
- 2:07Consumer Reports
- 2:48National Cyber Security Strategy
- 5:14EU Cyber Resilience Act
- 5:57NSA Memory Safety
- 6:45What is Memory Safety
- 8:16What is Safety
- 10:15Safety Properties
- 12:58Liveness Property
- 13:40Safety Property
- 15:20Safety Property Methods
- 17:20Memory Safe Language
- 18:03Memory Safety Example
- 19:26Whats the Problem
- 23:19What is a Memory Safety Safe Language
- 24:58Applying the Frame Rule to C
- 25:52Where does this leave C
- 27:43Understanding why software works
- 30:13The illusion of safety
- 38:36Can C be safe
- 40:00Future of Software Development
- 41:07Declarative Forms
- 43:02Large Language Models
- 47:58In desperation
related talks
01h 28mKeynote: Safety, Security, Safety and C / C++ - C++ Evolution
01h 04mC++ and Safety
45mThe existential threat against C++ and where to go from here
43mEverything I learned about static analysis and program safety in C++
26mUndefined Behavior in 2017 (part 2 of 2)
14mEmbedded C and C++: A Security Perspective
53mMaking C++ Fun, Safe, and Accessible
01h 32mClosing Keynote: C++ Development Tools: Past, Present and Future