C和C++标准如何规范未覆盖场景的处理方式？

众所周知，C和C++标准中都存在“盲区”，未对格式良好的程序中的某些场景进行描述。对于这类复杂的形式系统，其非形式化描述显然无法提前涵盖所有情况。

因此，在发布新版本标准之前，存在一套既定的标准修正与解释流程。我们以时间最早、最为典型的C90标准（ISO/IEC 9899:1990，现已正式废止）为例进行说明。

C90标准的修正文档（按重要性从高到低排序） #

1. ISO Technical Corrigendum (TC)
   这类文档实际上是直接应用于现有标准的“补丁”，具有追溯效力。这意味着，如果新标准文档对标准中的模糊部分做出了不同的澄清，所有此前自行解读这些模糊部分的合规实现都将变为不合规。
   针对C90发布了两份此类文档：TC-1:1994和TC-2:1996。

2. ISO Amendment (Amd)，又称ISO Normative Addendum (NA)
   其效力与TC非常相似，影响基本相同，但可通过某些机制限制追溯效力——例如引入新的__STDC_VERSION__值。
   ISO修正案通常内容重大且篇幅较长，因此发布频率极低。不过针对C90仍发布了一份：Amd-1:1995。

3. WG14 Defect Report (DR)，又称Clarification Request
   这些是提交给标准化委员会的信函，用于请求澄清标准中有争议的内容，或提请关注标准中的各类缺陷。委员会会处理这些请求，公开表达集体意见，这些意见可能会纳入正式批准的文档（TC、NA甚至标准本身）。
   但Defect Report本身并非官方文档，因此不具备强制追溯效力。不过实现者和普通开发者可参考这些报告，避免未来出现不合规情况，或至少降低此类风险。
   针对C90标准（包括上述所有补充内容），共处理了178份报告，相关列表可在委员会官网查询。

由于标准未提供编译器或标准库的参考（模型）实现，因此需要持续对标准进行澄清与修订。并非所有实现者都有意完整支持新标准，也并非所有开发者都愿意重写维护的旧代码——这是行业现实。但显然无法无限期地为旧标准发布TC和DR。

由此引出以下问题：

1. 对于未明确标注为implementation-defined、unspecified甚至undefined的规格不足行为，应如何处理？
2. 在此类情况下是否应参考新标准？
3. 是否应为已废止的标准提交Defect Report？

请注意，本文讨论对象不仅包括编译器和标准库程序员，还包括普通代码编写者。

另请参阅 #

• 《Undefined Behavior背后的设计理念》

内容的提问来源于stack exchange，提问作者cher-nov