An Alternative to Rewriting Memory-Unsafe Code in Rust: the ‘Safe C++ Extensions’ Proposal
“After two years of being beaten with the memory-safety stick, the C++ community has published a proposal to help developers write less vulnerable code,” reports the Register.
“The Safe C++ Extensions proposal aims to address the vulnerable programming language’s Achilles’ heel, the challenge of ensuring that code is free of memory safety bugs…”
Acknowledging the now deafening chorus of calls to adopt memory safe programming languages, developers Sean Baxter, creator of the Circle compiler, and Christian Mazakas, from the C++ Alliance, argue that while Rust is the only popular systems level programming language without garbage collection that provides rigorous memory safety, migrating C++ code to Rust poses problems. “Rust lacks function overloading, templates, inheritance and exceptions,” they explain in the proposal. “C++ lacks traits, relocation and borrow checking. These discrepancies are responsible for an impedance mismatch when interfacing the two languages. Most code generators for inter-language bindings aren’t able to represent features of one language in terms of the features of another.”
Though DARPA is trying to develop better automated C++ to Rust conversion tools, Baxter and Mazakas argue telling veteran C++ developers to learn Rust isn’t an answer… The Safe C++ project adds new technology for ensuring memory safety, Baxter explained, and isn’t just a reiteration of best practices. “Safe C++ prevents users from writing unsound code,” he said. “This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety.” Baxter said that rewriting a project in a different programming language is costly, so the aim here is to make memory safety more accessible by providing the same soundness guarantees as Rust at a lower cost. “With Safe C++, existing code continues to work as always,” he explained. “Stakeholders have more control for incrementally opting in to safety.”
The next step, Baxter said, involves greater participation from industry to help realize the Safe C++ project. “The foundations are in: We have fantastic borrow checking and initialization analysis which underpin the soundness guarantees,” he said. “The next step is to comprehensively visit all of C++’s features and specify memory-safe versions of them. It’s a big effort, but given the importance of reducing C++ security vulnerabilities, it’s an effort worth making.”
Read more of this story at Slashdot.
“After two years of being beaten with the memory-safety stick, the C++ community has published a proposal to help developers write less vulnerable code,” reports the Register.
“The Safe C++ Extensions proposal aims to address the vulnerable programming language’s Achilles’ heel, the challenge of ensuring that code is free of memory safety bugs…”
Acknowledging the now deafening chorus of calls to adopt memory safe programming languages, developers Sean Baxter, creator of the Circle compiler, and Christian Mazakas, from the C++ Alliance, argue that while Rust is the only popular systems level programming language without garbage collection that provides rigorous memory safety, migrating C++ code to Rust poses problems. “Rust lacks function overloading, templates, inheritance and exceptions,” they explain in the proposal. “C++ lacks traits, relocation and borrow checking. These discrepancies are responsible for an impedance mismatch when interfacing the two languages. Most code generators for inter-language bindings aren’t able to represent features of one language in terms of the features of another.”
Though DARPA is trying to develop better automated C++ to Rust conversion tools, Baxter and Mazakas argue telling veteran C++ developers to learn Rust isn’t an answer… The Safe C++ project adds new technology for ensuring memory safety, Baxter explained, and isn’t just a reiteration of best practices. “Safe C++ prevents users from writing unsound code,” he said. “This includes compile-time intelligence like borrow checking to prevent use-after-free bugs and initialization analysis for type safety.” Baxter said that rewriting a project in a different programming language is costly, so the aim here is to make memory safety more accessible by providing the same soundness guarantees as Rust at a lower cost. “With Safe C++, existing code continues to work as always,” he explained. “Stakeholders have more control for incrementally opting in to safety.”
The next step, Baxter said, involves greater participation from industry to help realize the Safe C++ project. “The foundations are in: We have fantastic borrow checking and initialization analysis which underpin the soundness guarantees,” he said. “The next step is to comprehensively visit all of C++’s features and specify memory-safe versions of them. It’s a big effort, but given the importance of reducing C++ security vulnerabilities, it’s an effort worth making.”
Read more of this story at Slashdot.