为什么不建议在空间/辐射环境中使用 C 模板？

Question

通过阅读 这个问题，我明白了为什么在辐射高的环境（如太空或核电站）中不建议使用动态分配或例外。关于模板，我不明白为什么。你能给我解释一下吗？

考虑到 这个答案，它说使用起来非常安全。

注意：我不是在谈论复杂的标准库内容，而是专门制作的自定义模板。

原文由 Guillaume D 发布，翻译遵循 CC BY-SA 4.0 许可协议

Answer 1

请注意，与太空兼容（ 抗辐射、符合 航空）的计算设备非常昂贵（包括在太空中 发射，因为它们的重量超过公斤），并且单个太空任务可能花费数亿欧元或美元。由于软件或计算机问题而失去任务通常会带来高昂的成本，因此是不可接受的，并且证明了您甚至不会梦想用于开发手机小程序的昂贵的开发方法和程序是合理的，并且建议使用 概率推理 和工程方法，因为 宇宙射线 在某种程度上仍然是一个“不寻常的”事件。从高级的角度来看，宇宙射线及其产生的比特翻转可以被认为是某种抽象形式的信号或输入的噪声。您可以将“随机位翻转”问题视为 信噪比 问题，然后 随机算法 可以提供有用的概念框架（特别是在元级别，即在 分析 您的安全关键源代码或编译时二进制，而且在关键系统运行时，在一些复杂的内核或线程 调度程序 中），具有 信息论 的观点。

为什么不建议在空间/辐射环境中使用 C++ 模板？

该建议是对 C++、 MISRA C 编码规则和 嵌入式 C++ 规则以及 DO178C 建议的 概括，它与辐射无关，而是与嵌入式系统有关。由于辐射和振动的限制，任何太空火箭计算机的嵌入式硬件都必须非常小（例如，出于 经济 和能源消耗的原因，在计算机功率方面，它更像是一个类似 Raspberry Pi 的系统，而不是大型 x86 服务器系统）。太空硬化芯片的成本是民用芯片的 1000 倍。在嵌入空间的计算机上计算 WCET 仍然是一项技术挑战（例如，由于 CPU 缓存 相关问题）。因此， 堆分配 在 安全关键的 嵌入式软件密集型系统中是不受欢迎的（你将如何处理这些内存不足的情况？或者你如何 证明 你有足够的 RAM 来处理 所有 实时运行时的情况？）

请记住，在对安全 至关重要的软件世界 中，您不仅要以某种方式“保证”或“承诺”，而且肯定会评估（通常使用一些聪明的概率推理）您自己软件的质量，而且还要评估所有用于测试的软件工具的质量。构建它（特别是：您的编译器和链接器；Boeing 或 Airbus 不会在未经 FAA 或 DGAC 等事先 书面 批准的情况下更改用于编译其飞行控制软件的 GCC 交叉编译器版本）。您的大多数软件工具都需要以某种方式获得批准或认证。

请注意， _在实践中_，大多数 C++（但肯定不是全部）模板在内部使用堆。标准 C++ 容器 当然可以。编写 从不 使用堆的模板是一项困难的练习。如果您有能力，您可以安全地使用模板（假设您确实信任您的 C++ 编译器及其模板扩展机制，这是最新 C++ 编译器（例如 GCC 或 Clang ）的 C++ 前端中最 棘手 的部分）。

我猜出于类似（工具集可靠性）的原因，不赞成使用许多 源代码生成 工具（进行某种 元编程，例如发出 C++ 或 C 代码）。请注意，例如，如果您在某些安全关键软件（由 make 和 gcc 编译）中使用 bison （或 RPCGEN ）来评估，您需要并且可能进行详尽的测试）不仅 gcc 和 make ，而且 bison 。这是工程原因，而不是科学原因。请注意，一些嵌入式系统可能会使用 随机算法，特别是巧妙地处理 嘈杂 的输入信号（甚至可能是由于足够稀有的宇宙射线导致的随机位翻转）。证明、测试或分析（或只是评估）这种基于随机的算法是一个相当困难的话题。

还要查看 Frama-Clang 和 CompCert 并观察以下内容：

• C++11 （或以下） 是一种极其复杂的编程语言。它没有完整的 形式语义。精通 C++ 的人在世界范围内只有几十人（可能大部分都在其标准委员会中）。我能够用 C++ 进行编码，但无法解释移动语义或 C++ 内存模型 的所有微妙角落案例。此外，C++ 在实践中需要许多优化才能有效使用。

• 制作一个无错误的 C++ 编译器非常困难，特别是因为 C++ 实际上需要棘手的 优化，并且因为 C++ 规范的复杂性。但是当前的（比如最近的 GCC 或 Clang）在实践中非常好，并且它们几乎没有（但仍然有一些）残留的编译器错误。目前还没有适用于 C++ 的 CompCert++，制作一个需要数百万欧元或美元（但如果您能收到这么多钱，请通过电子邮件与 我 联系，例如 [e-mail] ，我的工作电子邮件）。而空间软件行业则 极为 保守。

• 很难制作一个好的 C 或 C++ 堆内存分配器。编码一个是权衡的问题。开个玩笑，考虑 将此 C 堆分配器 调整为 C++。

• 在 2019 年第二季度，模板相关 C++ 代码的 安全属性（特别是缺乏 竞争条件 或 未定义行为，例如运行时的缓冲区溢出） 仍然略领先于 C++ 代码的 静态程序分析 技术.我的 Bismon 技术报告草案（它是 H2020 可交付成果草案，因此请跳过欧洲官僚的页面）有几页更详细地解释了这一点。 注意 赖斯定理。

• 整个系统的 C++ 嵌入式软件测试 可能需要火箭发射（a la Ariane 5 test flight 501 ，或者至少在实验室进行复杂和繁重的实验）。它 非常 昂贵。即使在地球上测试 火星探测器 也需要 很多 钱。

想一想：您正在编写一些对安全至关重要的嵌入式软件（例如，用于火车制动、自动驾驶汽车、自动无人机、大型石油平台或炼油厂、导弹等）。你天真地使用了一些 C++ 标准容器，例如一些 std::map<std::string,long> 。内存不足的情况应该怎么办？您如何“证明”或至少“说服”在资助 1 亿欧元太空火箭的组织中工作的人们，您的嵌入式软件（包括用于构建它的编译器）足够好？十年前的规则是禁止任何类型的动态堆分配。

我不是在谈论复杂的标准库内容，而是专门制作的自定义模板。

即使这些也很难证明，或者更一般地难以评估它们的质量（并且您可能希望在它们内部使用自己的 分配器）。在空间中，代码空间是一个强约束。因此，您将使用例如 g++ -Os -Wall 或 clang++ -Os -Wall 进行编译。但是你是如何证明——或者简单地测试—— 所有 由 -Os 所做的细微优化（这些特定于你的 GCC 或 Clang 版本）？您的太空资助组织会问您，因为嵌入式 C++ 太空软件中的任何运行时错误都可能导致任务崩溃（再次阅读有关 Ariane 5 首次飞行 失败的信息 - 以 Ada 的某种方言编码，当时有“更好”和“比今天的 C++17 更安全”的类型系统），但不要过多地嘲笑欧洲人。带有 MACS 的 波音 737 MAX 也是 一团糟）。

---

我个人的建议（但请不要太认真。在 2019 年，它更像是一个双关语）是考虑用 Rust 编写你的空间嵌入式软件。因为它比 C++ 稍微安全一些。当然，您必须在 5 或 7 年内花费 5 到 10 M€（或 MUS$）才能获得适合太空计算机的优质 Rust 编译器（再次，请专业联系我，如果您有能力花那很多关于免费软件 Compcert/Rust 之类的编译器）。但这只是软件工程和软件项目管理的问题（请阅读 Mythical Man-Month 和 Bullshit 工作 了解更多信息，还要注意 Dilbert 原则：它适用于太空软件行业或嵌入式编译器行业，以及还要别的吗）。

我强烈的个人意见是，欧盟委员会应该资助（例如通过 Horizon Europe ）一个 免费软件 CompCert++（或者甚至更好，一个 Compcert/Rust）类似项目（这样一个项目需要超过 5 年和超过 5 个顶级级，博士研究人员）。但是，在 60 岁的时候，我很遗憾地知道这不会发生（因为欧共体的意识形态——主要是出于显而易见的原因受到德国政策的启发——仍然 是历史终结 的幻觉，所以 H2020 和 Horizon Europe 处于实践，主要是通过欧洲 避税天堂 为欧洲公司实施税收优化的一种方式），并且在与 CompCert 项目的几位成员进行了几次私下讨论之后。我很遗憾地期望 DARPA 或 NASA 更有可能资助一些未来的 CompCert/Rust 项目（而不是 EC 资助它）。

---

注意。欧洲航空电子工业（主要是空中客车）正在使用比北美（波音）更 正式的方法。因此避免了 _一些_（不是全部）单元测试（因为被源代码的 正式证明 取代，可能使用 Frama-C 或 Astrée 之类的工具 - 两者都没有经过 C++ 认证，仅适用于 C 的一个 _子集_，禁止 C 动态内存分配 和几个C) 的其他特点。这是 DO-178C （而不是前身 DO-178B ）允许的，并得到了法国监管机构 DGAC 的批准（我猜是其他欧洲监管机构）。

另请注意，许多 SIGPLAN 会议与 OP 的问题 间接 相关。

原文由 Basile Starynkevitch 发布，翻译遵循 CC BY-SA 4.0 许可协议