众所周知，在每个 C 和 C++ 标准中都存在“盲点”，这些“盲点”没有描述格式良好的程序中的某些情况。显然，在如此复杂的形式系统的非形式化描述中，不可能提前注意到一切。
因此，在发布新的修订版（“版本”）之前，有一个纠正和解释标准的既定程序。让我们使用最简单且按时间顺序排列的第一个示例来考虑此过程 - C90 标准 (ISO/IEC 9899:1990)。
为此发布了以下类型的文件，按重要性递减排列：
ISO 技术勘误表 (TC)
事实上，这些是一种直接应用于现有标准并具有追溯效力的“补丁”。实际上，这意味着，如果新文档以其他方式澄清了这些地方，那么所有以前以自己的方式解释标准模糊部分的合规实现都会变得不合规。
ISO 修正案 (Amd)，又名 ISO 规范附录 (NA)
与 TC 的效果非常相似，并且实际上具有相同的影响，但可能通过某种机制限制其追溯效果 - 例如通过引入新值
__STDC_VERSION__通常，ISO 修正案意义重大且规模庞大，因此很少发布。但对于 C90，仍然发布了 - Amd-1:1995。
WG14 缺陷报告（DR）
这些是致标准化委员会的信函，要求澄清标准中某些有争议的段落，并提请注意标准中的各种缺陷。委员会对这些问题进行讨论，公开表达其集体意见，最终可能会出现在正式批准的文件中（TC、NA 甚至标准本身）。
但是，缺陷报告本身并不是正式文件，因此不具有强制性追溯效力。尽管如此，实施者和普通开发人员可以依靠它们来避免未来不合格的命运，或者至少减少其发生的可能性。
对于C90标准，包括所有上述补充内容，已处理了178份报告，其列表可在委员会的官方网站上找到：
https://www.open-std.org/jtc1/sc22/wg14/www/docs/dr.htm
https://www.open-std.org/jtc1/sc22/wg14/www/docs/c90_drs.html
由于标准既不为编译器也不为标准库提供参考（模型）实现，因此需要不断澄清和编辑。并非所有实施者都可能有兴趣完全支持新标准，也并非所有开发人员都希望重写他们维护的旧代码 - 这是生活和商业的事实。但也很明显，TC和DR不能无限地为旧标准颁发。
因此，出现以下问题：
如何处理未明确声明为“实现定义”、“未指定”甚至“未定义”的未指定行为？ 在这种情况下是否应该使用更新的标准？