C++ 内存安全的未来：从 Safety Profiles 到 Safe C++

C++ 的内存安全正在形成两条值得关注的技术路线：一条是在现有 C++ 上逐步强化安全规则，另一条是在 C++ 内部建立具有严格安全保证的语言子集。

前者强调渐进式改进，后者尝试从语言机制层面解决内存安全问题。

一、C++ 内存安全的两条路线

1. Safety Profiles：渐进式安全

Safety Profiles 的思路是在现有 C++ 基础上定义一组安全规则，通过静态分析、编译器诊断和代码约束，减少常见的内存安全错误。

其特点是：

尽量兼容现有 C++ 代码。
逐步检查生命周期、指针使用和资源管理等问题。
可以结合编译器和 CI，持续强化项目的安全约束。
不要求一次性重构整个项目。

这种路线更适合已有大量 C++ 代码的工业项目，但具体安全保证取决于规则的覆盖范围、分析能力和执行方式。

2. Safe C++：语言级安全子集

Safe C++ 的目标是在 C++ 的超集中建立一个具有严格安全保证的子集。

它不仅检查代码，还尝试通过语言规则限制可能产生未定义行为的操作，并引入借用检查、生命周期约束和新的类型机制。

其设计方向包括：

在安全上下文中禁止可能破坏内存安全的操作。
通过编译期分析检测悬空引用、迭代器失效等问题。
将不安全操作明确标记出来，方便审查。
为不安全的传统接口提供更安全的替代机制。

它的目标不是另起炉灶创造一门完全独立的语言，而是在保留 C++ 生态的基础上扩展安全能力。

二、WG21 相关提案

以下资料分别涉及 Safe C++ 的设计、内存安全方向和 Profiles 的规划。

1. P3390R0 --- Safe C++

原文：P3390R0 --- Safe C++

这份提案介绍了 Safe C++ 的总体设计，包括安全上下文、借用检查、显式可变性、对象重定位以及新的选择类型等机制。

其中值得关注的是：

safe：用于标记安全函数，使函数实现受到安全规则约束。
unsafe：用于显式标记需要承担安全责任的不安全操作。
Borrow Checking：通过编译期分析检测悬空引用、生命周期冲突和迭代器失效等问题。
安全标准库：提供适配安全模型的容器、引用和类型。

需要注意，P3390R0 是提案，不代表这些语法和机制已经成为 ISO C++ 标准。

2. P3700R0 --- Making Safe C++ Happen

原文：P3700R0 --- Making Safe C++ Happen

这份资料关注如何推动 Safe C++ 的实现与落地，涉及推进路径、实现工作和相关协作。

它体现了一个重要区别：提出安全机制只是第一步，还需要编译器实现、标准库支持、工具链配套和实际工程验证。

3. P3874R1 --- Should C++ be a memory-safe language?

原文：P3874R1 --- Should C++ be a memory-safe language?

这份资料讨论 C++ 是否应当以实现内存安全为重要语言目标。

它属于理解 C++ 内存安全方向的重要材料，但需要区分提案作者的主张、委员会内部讨论结果和最终标准决定。即使某个方向获得相关工作组的积极支持，也不等于 WG21 已经正式确定完整方案。

4. P4186R0 --- A Proposed Plan for Profiles in C++

原文：P4186R0 --- A Proposed Plan for Profiles in C++

这份资料关注 C++ Profiles 的规划方向。

Profiles 的思路是逐步建立可执行的安全规则，使现有 C++ 项目能够在兼容性与安全性之间作出更可控的选择。

提案的存在并不意味着 Profiles 已经成为正式标准功能，也不能据此认定某个具体版本必然包含全部能力。

三、Safe C++ 中的 `safe` 与 `unsafe`

根据：P3390R0 ，safe 放在函数声明之后。

1. `safe`：安全函数与安全上下文

示例：

cpp 复制代码

int main() safe {
    // 安全上下文
}

void process_data() safe {
    // 函数实现受到安全规则约束
}

这里的 safe 是函数的安全标记。

在提案设计中，安全函数的实现必须遵守相应的安全规则。可能产生未定义行为的操作不能直接在安全上下文中任意执行。

需要强调的是，safe 并不是给普通 C++ 函数添加一个装饰性标签。它意味着编译器需要根据提案定义的规则，对函数体及其调用进行安全性约束。

2. `unsafe`：显式进入不安全上下文

在安全函数中，有时仍然需要调用底层指针接口或执行无法由编译器独立证明安全的操作。Safe C++ 的设计允许通过显式的 unsafe 标记承担相应责任。

示例：

cpp 复制代码

int read_value(const int* p) safe {
    unsafe {
        return p[0];
    }
}

这个例子是用于说明语法意图的示意代码，并不是可以直接用于普通 C++ 编译器的标准 C++ 代码。

unsafe 块允许在其中执行相应的不安全操作，但它不意味着这些操作自动变得安全。程序员仍然必须保证指针有效、访问范围正确、对象生命周期满足要求等前置条件。

3. 两者的核心区别

标记	作用	责任
`safe`	声明安全函数，约束其实现与调用	安全保证应由语言规则、编译器和接口契约支撑
`unsafe`	显式进入不安全上下文，允许相应的不安全操作	程序员承担这些操作的正确性责任

这套设计的关键，是把安全与不安全的边界显式化，让审查者能够优先检查 unsafe 出现的位置。

此外，提案还讨论了 unsafe 类型限定等更复杂的互操作机制，不能将 unsafe 的所有用途都简单等同于 unsafe { ... } 块。

以上均为 P3390R0 所描述的提案设计，不应当视为已定稿的 ISO C++ 语法。

四、生命周期分析与 Borrow Checking

生命周期问题是 C++ 内存安全的重要组成部分。

例如：

cpp 复制代码

std::string_view get_text() {
    std::string text = "hello";
    return text;
}

这里返回的 std::string_view 不拥有字符串内容。函数返回后，局部变量 text 已经销毁，返回的视图因此悬空。

传统 C++ 允许这种代码通过编译，问题可能在后续访问时暴露。

Safe C++ 希望通过借用检查等机制，在编译期识别这种生命周期冲突。

但必须区分两个概念：

Lifetime Analysis：生命周期分析，可以检查特定的生命周期错误。
Borrow Checking：借用检查，进一步追踪借用关系、对象使用范围和冲突操作。

二者相关，但不能简单地认为任何生命周期分析都等价于 Rust 式的完整 Borrow Checker。

五、Safety Profiles 与 Safe C++ 的区别

对比维度	Safety Profiles	Safe C++
核心思路	为现有 C++ 增加安全规则	建立具有严格安全保证的语言子集
兼容性	倾向于渐进式兼容	保留 C++ 基础，同时增加安全约束
主要手段	规则检查、静态分析、诊断和约束	安全上下文、借用检查、类型与对象模型等
代码改造	可逐步应用于现有项目	可能需要调整接口、类型和编程方式
安全保证	取决于具体规则及分析覆盖范围	目标是在受约束的安全子集中提供更强的保证
主要挑战	规则覆盖、误报、既有代码兼容性	编译器实现、标准库适配、遗留代码互操作

两条路线并不必然互斥。它们的共同目标是减少内存安全漏洞，但实现路径和所能提供的保证不同。

六、为什么 C++ 需要进一步强化内存安全

C++ 被广泛用于操作系统、基础设施、嵌入式设备和高性能服务。这些领域对性能、资源控制和既有生态有很强的依赖。

与此同时，裸指针、手动资源管理、悬空引用、越界访问和数据竞争等问题，也会带来持续的安全风险。

CISA、NSA 等机构发布过关于内存安全风险的指导文件，推动软件制造商制定内存安全路线图。

七、C++ 安全化面临的工程挑战

1. 遗留代码与生态兼容

C++ 拥有庞大的历史代码库和第三方库生态。

如果引入更严格的安全规则，必须处理传统指针接口、容器、模板、资源管理和外部库之间的互操作问题。

Safe C++ 的一个设计重点，就是让安全代码能够在明确边界下与传统 C++ 代码共存。

2. 编译器与标准库实现

安全规则只有被工具链正确实现，才能转化为实际保障。

这需要编译器前端、静态分析、中间表示、标准库和调试工具等配套工作。复杂的借用检查与对象模型变更，也会增加实现和验证成本。

3. 性能与表达能力

安全检查并不必然意味着运行时开销。

部分检查可以在编译期完成；某些越界检查则可能需要运行时机制。具体开销取决于设计、优化能力和使用场景。

同时，安全子集必须足够有表达能力，才能支持真实的系统编程，而不只是编写简单的示例程序。

八、C++29 与 C++32：只能作为技术推演

可以从技术演进的角度设想：

一个阶段逐步完善安全规则、静态分析和 Profiles。
后续阶段进一步推进语言级安全子集、借用检查和标准库适配。

但将这些阶段分别对应到 C++29、C++32，只能视为个人推演，不能当作 WG21 已经确定的标准路线图。

标准功能是否进入某一版本，取决于提案成熟度、委员会讨论、实现经验以及最终的标准化决策。

同样，不能仅凭某份提案就断言 GCC 17 或某个特定版本已经完整实现 Profiles 或 Safe C++。

九、工业项目应该如何应对

不必等待 Safe C++ 完全标准化，现有项目就可以采取可落地的安全措施。

建议重点关注：

所有权与生命周期：优先采用 RAII，避免返回指向局部对象的引用或视图。
边界表达 ：合理使用 std::span 等类型表达指针与长度的关系，避免无约束的裸指针接口。
静态分析：在 CI 中启用编译器警告、静态分析和适用的安全规则。
动态检测：在测试环境使用 AddressSanitizer、UndefinedBehaviorSanitizer 等工具发现实际运行中的问题。
底层接口隔离：把确实需要裸指针或不安全操作的部分限制在较小、可审计的接口边界内。
持续验证：通过单元测试、边界测试、压力测试和回归测试验证安全约束。

这些措施能够降低风险，但不能直接等同于完整的编译期内存安全保证。

十、总结

C++ 内存安全的未来，可以从两条路线理解：

Safety Profiles：在现有 C++ 上逐步强化安全规则，重视渐进式应用和兼容性。
Safe C++：在 C++ 内部建立具有严格安全保证的子集，尝试从语言机制层面约束内存不安全行为。

Safe C++ 的关键不只是 safe 这个标记，而是安全上下文、借用检查、类型系统、对象模型和标准库协同形成的安全机制。unsafe 则明确标出需要程序员承担正确性责任的操作边界。

从方向上看，C++ 正在探索从"尽可能发现错误"走向"对受约束代码提供更强的系统性安全保证"。

但具体采用哪些机制、何时进入正式标准，以及各个版本能够提供多少能力，仍然必须以 WG21 的正式进展和实际实现为准。

C++ 内存安全的未来：从 Safety Profiles 到 Safe C++