C++ and Safety

Organisations such as the National Security Angency (NSA) and the National Institute of Standards and Techology (NIST) are currently urging developers to move away from programming languages that are not memory safe. C++ is arguably not a "safe" programming language in its current form. Why is that? And should we do anything about it? If yes, what, and how? Have we arrived at a crossroads for the future evolution of C++? What does "safety" even mean, and how is it different from "security" and "correctness"?

In this talk, we attempt to give useful definitions for these terms. For safety in particular, we can distinguish between functional safety and language safety, and identify different aspects of language safety (of which memory safety is one). We discuss how and why C++ is considered "unsafe" and what consequences follow from that for different domains and use cases. We look at how other programming languages, such as Java, Rust, and Val avoid such safety issues, what tradeoffs are involved in these strategies, and why we can't easily adopt any of them for C++. We consider the tooling available today to mitigate safety issues in C++, such as sanitisers and static analysers, and their limitations. Finally, we look at the future evolution of C++ and discuss the current work on C++ Contracts and other recent proposals targeted at making C++ more safe.