Safe C++ is a new Proposal to Make C++ Memory-Safe

Write for InfoQ

The goal of the Safe C++ proposal is to extend C++ by defining a superset of the language that can be used to write code with strong safety guarantees, similar to code written in Rust. The key to its approach is introducing a new safe context where only a rigorously safe subset of C++ is allowed.

The Safe C++ proposal, set forth by Sean Baxter and Christian Mazakas, originates from the growing awareness that C++ memory unsafety lies at the root of a large part of vulnerabilities and memory exploits. The only existing safe language, say Baxter and Mazakas, is Rust, but their design differences limit interoperability, thus making it hard to migrate from one language to the other. For example, Rust lacks function overloading, templates, inheritance, and exceptions, while C++ lacks traits, relocation, and borrow checking.

Given this context, Safe C++ aims to provide a smoother path that ensures existing code can be compiled with no problem and users can opt it to the new safe language features to migrate existing code incrementally or write new code that work together with unsafe code.

Safe C++ developers are prohibited from writing operations that may result in lifetime safety, type safety or thread safety undefined behaviors. Sometimes these operations are prohibited by the compiler frontend, as is the case with pointer arithmetic. Sometimes the operations are prohibited by static analysis [...] The remainder of issues, like out-of-bounds array subscripts, are addressed with runtime panic and aborts.

One key aspect of the Safe C++ proposal is that its safe subset must remain useful, say their proponents. This means that if some C++ features like pointers and unions are removed, they must be replaced by equivalent but safe alternatives that will also improve language expressiveness and developers' experience.

For example, the Safe C++ proposal includes pattern matching, choice types, and borrowing. To ensure thread-safety and minimize the risk of data races causing undefined behavior, Safe C++ adopts send and sync type traits similarly to what found in Rust.

The proposal also introduces explicit mutation for references, which is required by the borrowing system, and a model for object relocation, which is standard in Rust but unusual for C++ programmers who are used to managing raw pointers and legacy references tied to memory locations.

All of Safe C++ abstractions strive to honor the C++ goal of providing zero-cost abstractions.

As a final note about Safe C++, its definition is not complete yet, since several design issues are still unresolved. Those include function parameter ownership, non-static member functions with lifetimes, and relocation out of references.

Safe C++ is not the only approach to change C++ and make it a safe, or at least safer language. InfoQ has recently covered another such proposal, which is based on C++ profiles, a feature the ISO Committee is currently working on to address type safety, bounds safety, and lifetime safety.

Related Topics:

• Development
• C++
• System Programming
• Programming Languages
• Embedded Software Dev
• Safety

We protect your privacy.