C and C++'s Response to Memory Safety Concerns
This article explores how C and C++ developers are addressing the growing concerns about memory safety, particularly in light of government recommendations to adopt memory-safe languages like Rust. Instead of abandoning C and C++, some developers are actively working on solutions to bring memory safety into these languages.
The Pressure to Move Away from C and C++
The U.S. government, including CISA and the FBI, is strongly advocating for a shift from C and C++ to more memory-safe languages. CISA's website indicates that the lack of a published memory safety roadmap for existing products written in memory-unsafe languages by January 1, 2026, poses a significant risk to national security, economic stability, and public health. Their recommendation emphasizes that software manufacturers should build products that systematically prevent memory safety vulnerabilities.
This push stems from the prevalence of memory safety issues. Microsoft reported that approximately 70% of vulnerabilities addressed through security updates each year are related to memory safety. Google found that around 70% of serious security bugs in the Chromium project are memory safety problems. Mozilla reported that 94% of critical high bugs they analyzed were memory related. These issues include buffer overflows, use-after-free vulnerabilities, memory leaks, and null pointer dereferences.
Why Developers are Hesitant to Switch to Rust
Despite the clear need for improved memory safety, many C and C++ developers are reluctant to switch to languages like Rust. They cite the difficulty of learning a new language, the potential performance overhead, and the challenges of rewriting existing codebases. While Rust offers strong safety guarantees through its borrow checker, it may not offer enough advantages to justify the transition for developers comfortable with C and C++. Additionally, many underlying packages in memory-safe languages are still written in C.
Therefore, the focus has shifted towards finding ways to enhance the memory safety of C and C++ itself.
Three Approaches to Memory Safe C/C++
Here are three solutions, either available or under development, aimed at bringing memory safety to C and C++:
1. Safe C++ Project
-
Acknowledges the challenges of completely abandoning C++.
-
Aims to create a safe subset of C++ with strong safety guarantees, drawing inspiration from Rust concepts.
-
Key features include:
-
A safe context with a restricted subset of C++
-
Borrow checking
-
Initialization analysis
-
Pattern matching and choice types
-
Thread safety features
-
Explicit mutation
-
Object relocation model
-
-
Focuses on maintaining performance and zero-cost abstractions.
-
Currently a work in progress with no clear implementation timeline.
2. Phil C
-
Created by Philip Pizlo, aiming for 100% compatibility with C and C++.
-
Allows existing C/C++ code to be compiled with the Phil C compiler to achieve memory safety.
-
Designed without escape hatches, preventing linking to unsafe libraries.
-
Claims that most programs will compile and run without changes.
-
Limitations:
-
Currently only works on Linux
-
Can be 1.5 to 5 times slower than legacy C, with efforts to improve performance
-
-
Aims to obviate the need for Rust by achieving comparable performance.
3. Trap C
-
A newly proposed memory-safe variant of C, presented by Robin Row.
-
Essentially a fork of C designed to prevent common vulnerabilities such as buffer overflows, segmentation faults, and memory leaks.
-
Designed to be link-compatible with C using the same ABI.
-
Safety Features:
-
Pointers cannot cause segfaults or buffer overruns
-
Automatic memory management
-
No unsafe keyword
-
-
Syntax closely resembles C/C++, easing adoption for C programmers.
-
Includes C++ constructors and destructors.
-
Removes rarely used keywords and implements automatic bound checking and pointer nullification.
Conclusion
Instead of moving away from C and C++, many in the community are exploring ways to make these languages memory safe. The initiatives discussed above represent diverse approaches, each with its own set of trade-offs and potential benefits. The ultimate success of these efforts will depend on their ability to balance safety with performance and ease of adoption.