A group working on the development of the hugely popular C++ programming language has outlined a path to make the language “memory safe” — just like its younger rival, Rust.
Rust has been embraced by Microsoft, AWS, Meta, Google’s Android Open Source Project, the C++-dominated Chromium project (sort of), the Linux kernel, and many more, which has helped to reduce memory security flaws. Even the National Security Agency (NSA) has recommended developers make a strategic shift away from C++ in favor C#, Java, Ruby, Rust, and Swift.
Widespread warnings about C++ security have prompted moves to plot a path forward for the “Safety of C++”, detailed in a paper by a group including Bjarne Stroustrup, the creator of C++, for the C++ Standards Committee Working Group 21 (WG21), which was released this month.
ZDNET Recommends
The paper argues for technical changes and considers how C++ should address its “image problem” with safety.
Also: Programming languages: Why this old favorite is on the rise again
Apple is the latest tech giant to highlight security problems with C/C++ code in operating systems. The company is addressing memory safety in XNU, the kernel for iOS, macOS, watchOS, and more.
“Because nearly all popular user devices today rely on code written in programming languages like C and C++ that are considered “memory-unsafe,” meaning that they don’t provide strong guarantees which prevent certain classes of software bugs, improving memory safety is an important objective for engineering teams across the industry,” Apple explained in October.
C++ emerged in 1985 and remains one of the most popular languages, in part due to its performance. It is standardized by the International Organization for Standardization (ISO), the latest version of which is C++20, finalized in December 2020. The next standard is likely to be called C++2023. Rust, on the other hand, reached version 1.0 in 2015, and is not standardized but driven by its community of contributors.
The paper from Stroustrup and his peers talks up the use of C++ in safety critical domains, such as embedded, medical, aerospace, and avionics. They acknowledge there’s “increased demands for more formal constrains with regards to safety” because of the rise of autonomous vehicles, connected critical infrastructure, messaging apps, and so on.
“Applications such as embedded, automotive, avionics, medical, and nuclear were obvious applications that require safety if programmed in C++,” the authors write.
“So along the way, there were safety guidelines developed for most of these. The Internet explosion brought in browsers which were increasingly targets of hacking as more commercial transactions occur through browsers. Rust, originally from Mozilla, built on top of C++ became the poster child of a safe browser language. Increasingly we have seen RUST’s safety claims tested in more applications beyond browsers, e.g. drivers and Linux kernel.”
The paper notes the NSA’s recent recommendation for organizations to “consider making a strategic shift from programming languages that provide little or no inherent memory protection, such as C/C++, to a memory safe language when possible.”
“More recently, two developments involving US government publications advising the Safety applications not to use C/C++ from the NIST and NSA seems to have ignited a widespread discussion of safety within C++. Both NIST and NSA seem to suggest using an alternate language,” the paper says. The risk is that “non-government entities might ignore government directive AND/OR, government directive locks C++ out of certain market, and indirectly leads to a push away from C++”.
The paper notes that C++ has an image problem when it comes to safety, but puts that down to other languages marketing themselves as safe, which the authors argue ignores the advances in safety that C++ has made in recent years.
“C++ appears, at least in public image, less competitive than other languages in regards to safety. This seems true especially when compared to languages that advertise themselves more heavily/actively/brazenly/competently than C++. In some ways, they appear especially to satisfy an executive-suite definition of safety, which makes it attractive for executives to ask for a switch from C++,” the paper says.
Also: Low-code is not a cure for overworked IT departments just yet
“Yet what has been lost in the noise is that C++ has made great strides in recent years in matters of dangling, resource and memory safety… C++ benefits from having a specification, active community of users and implementers. Other “safe” languages may not even have any specification, at least not yet. These important properties for safety are ignored because we are less about advertising. C++ is also time-tested and battle tested in millions of lines of code, over nearly half a century.”
Other languages are not, it argues.
“There might come a time when C++ will pass on its torch to another greater language, but none of the current contenders are such. We should never abandon the millions of lines of existing code, some of which does not cry out for safety. We should recognize the urgency to support safety in C++ is one of the issues of our time.”
The paper says the C++ standards committee WG21 supports the idea that changes for safety need to be adopted not just in tooling — where it has done more work in the past — but also to be “visible” in the language/compiler and library to help address the image of C++ in relation to safety.
