Video thumbnail for 大危机!绝境中的C++要如何自救?【让编程再次伟大#34】

C++ in Crisis? How It Can Survive the Memory Safety Threat

Summary

Quick Abstract

Is C++ facing a memory safety crisis? A recent U.S. Department of State report highlights the critical impact of memory-unsafe languages like C++ on national security. This summary delves into a proposed solution called "Profiles," aimed at adding memory management capabilities to C++, and explores the challenges this faces within the C++ standardization process. Will it be enough to save C++?

Quick Takeaways:

  • U.S. government pushing for memory-safe languages due to security concerns.

  • "Profiles" framework proposed to introduce memory management to C++.

  • Profiles are OP-IN (default off), allowing gradual adoption and compatibility.

  • The framework is designed with a "Subset of Superset" approach for flexibility.

  • C++ inventor Bjarne Stroustrup's proposal was rejected by the WG21 committee.

  • Fragmentation within the C++ community poses a significant challenge to standardization and adoption.

  • Rust's rise highlights the demand for memory-safe languages, putting pressure on C++.

  • C++ faces a critical window for addressing memory safety before it's too late.

The Future of C++: Security Concerns and Potential Solutions

At the end of 2024, the U.S. Department of State released a security report, "Product Security by Practice," highlighting the risks associated with memory-unsafe languages like C and C++. The report indicated that software developed in these languages could pose significant threats to national security, economic stability, and medical safety. The report suggests software released in 2025 should utilize memory-safe languages to avoid being flagged as a national security risk.

Memory Safety: A Persistent Problem

The report objectively acknowledges that digital memory vulnerabilities have long been a leading issue in the software industry. Memory-related problems have caused major computer failures, as demonstrated in the MAPGA video series. While Western languages, particularly C and C++, face challenges, the emergence of new languages competing for market share creates further complications.

Bjarne Stroustrup's Proposal: The "Profiles" Framework

Bjarne Stroustrup, the creator of C++, addressed memory safety concerns at the C++26 preparatory meeting. He submitted a report to the technical committee, discussing non-technical aspects alongside the technical challenges. In response to government pressure and growing developer awareness of memory security, Stroustrup proposed a technical solution: a framework called "Profiles."

Profiles aims to provide C++ with memory management mechanisms and other security features that have historically been lacking. It is not an independent component like GCE but rather a transparent framework that functions as a rule engine. This engine can load various rules, such as checking the reading range of subgroups, ensuring correct type conversion of parameters, addressing empty index application issues, and enforcing garbage collection for all resources.

OP-IN Design and Strong Guarantees

A key feature of Profiles is its "OP-IN" design, meaning it is disabled by default. It only activates when a specific profile is enabled, allowing existing code to remain unchanged and potentially unsafe if desired. Furthermore, Profiles provides strong execution guarantees, similar to the enforced execution of TypeScript, rather than merely providing suggestions like a lint plugin.

The "Subset of Superset" Concept

Profiles' design philosophy mirrors that of C++ itself, which is often described as "Subset of Superset." This involves expanding capabilities (e.g., adding classes and templates) and then applying restrictions to enhance safety and stability. Profiles expands the standard library's capabilities, enabling more compile-time and runtime checks, and then uses profiles to enforce usage rules, creating a safer environment.

Technical Merits of Profiles

The proposed design effectively addresses internal C++ loopholes and mitigates potentially problematic operations. It considers the existing C++ codebase, ensuring compatibility without introducing new issues. Stroustrup's efforts aim to provide C++ with a new lease on life, giving it memory management without breaking existing code.

The Standardization Process: A Committee-Driven Approach

Adding features to the core of C++ is a complex process. Stroustrup, while the creator of C++, does not have unilateral authority. Since 1990, C++'s technical direction has been determined by the WG21 working group within ISO. All technical solutions must be submitted to the technical committee and approved by a vote.

Stroustrup's Return and the WG21 Decision

Stroustrup led the development of C++ through the 1990s, including the first ISO standard, C++98. After stepping down from WG21 in 2002, he returned after 23 years to directly participate with this proposal, highlighting the importance of the issue to him. However, WG21 ultimately did not accept the proposed development route for C++26.

The Threat from Rust and Community Fragmentation

The survival of C++ is threatened not only by external pressures, such as US government scrutiny, but also by internal factors. Rust serves as a catalyst for highlighting the advantages of memory-safe languages. The emergence of Rust has indirectly promoted the acceleration of internal security issues.

C++ inherited technical debts from the C language, starting its journey with potential vulnerabilities. Early attempts to address these, such as the RAII mechanism and smart pointers, were limited. The community has developed various static analysis tools and extension functions to improve security, but their lack of standardization has led to fragmentation. This lack of shared code, tools, and development experience hinders the adoption of standardized memory management. Developers may cling to older versions for compatibility, repeating the difficulties seen with Python 2 to 3.

A Critical Window of Opportunity

Similar to trends in data warehouse development, C++ faces a critical window of opportunity. Missing this window could limit the impact of even the best solutions. The question remains whether this window will still be open when C++29 or C++32 are released. Whether C++ eventually adopts Profiles or a superior solution, timing is critical for long-term success.

Was this summary helpful?