后续问题：不受支持的标准功能会影响一致性吗？.
问题：如果一个实现支持 C 标准中没有描述的额外特性，也没有在任何“扩展文档”中描述，那么这样的实现是否符合要求？
一个简单的例子：#pragma STDC FP_CONTRACTrequires on-off-switch，它是 之一ON OFF DEFAULT。但是，除了ON OFF DEFAULT支持RESTORE. 因此，这种实现允许编写非标准代码。这是否意味着这样的实现是不合格的？
额外的问题：C 标准告诉“实现应该/应该做什么”。但是，C 标准（或任何一般标准）是否告诉“应该/不应该做什么实现”？例如，如果一个实现确实支持my_printf（除了printf），那么这样的实现是否符合要求？
该标准定义了三个一致性概念。按照意义的顺序，它们是“严格符合 C 程序”、“符合 C 实现”和“符合 C 程序”。
严格符合 C 的实现是其行为完全由标准指定的实现。这不包括所有用于独立实现的重要程序，因为标准没有为它们定义任何形式的 I/O。它还排除了许多可移植的程序，如果标准试图避免将其行为可能难以在某些实现上定义，或者其行为可能暴露有用优化的效果的任何行为表征为 UB。
符合标准的 C 实现在理论上可以在理论上有意义地处理所有严格符合的程序，但在给定任何超出实现的翻译限制的程序（严格符合或不符合）时可能会表现得任意。后一个警告创造了一个大到足以让卡车通过的漏洞。
虽然标准要求实现能够容纳例如 127 个嵌套块、块内的 511 个块范围标识符、结构或联合中的 1023 个成员以及内部标识符名称中的 63 个字符，但它并不要求实现能够容纳 127 个嵌套块，每个块具有 511 个标识符，每个标识符标识一个具有 1023 个成员的结构，每个成员的名称长度为 63 个字符。这样的要求将使该语言无法在存储空间少于 4 GB 的任何翻译环境中得到支持。为了避免使语言无法实现，标准不要求实现支持翻译限制的任意组合。反而，一致性所需要的只是存在一些程序——可能是人为的和无用的程序——名义上至少单独地执行每个限制。作者承认，在已发表的基本原理中，这样的要求非常薄弱：
该标准要求实现能够翻译和执行满足每个规定限制的某些程序。该标准被认为为实现者在满足这些限制方面提供了有用的自由度。虽然有缺陷的实现可能会设计出满足此要求的程序，但仍然会成功地变得无用，但 C89 委员会认为，这种独创性可能需要比做出有用的东西更多的工作
我认为他们高估了所需的“独创性”，但我认为关键在于标准是否认为符合一种实现，例如允许程序具有一个 63 个字符长的标识符并限制所有其他用户标识符对于太多的字符，任何想出售编译器的人都不会施加这样的限制。因此，虽然标准对“符合 C 实现”的定义实际上没有意义，但它仍然为非垃圾质量实现建立了一些基线期望。
至于“符合 C 程序”的概念，该术语被定义为包括被宇宙中某个地方的至少一个符合 C 实现所接受的任何程序。这显然太宽泛而没有意义；我认为关键在于委员会希望避免将任何有用的程序归类为不合格项目。再次从基本原理（斜体原文）：
严格符合程序是最大可移植程序的另一个术语。目标是让程序员有机会制作功能强大且高度可移植的 C 程序，而不会贬低恰好不可移植的完全有用的 C 程序，因此副词strict。
C 实现明确授予对语言添加扩展的自由度，无论是在语法上还是通过在标准没有要求的情况下定义行为（通常以“以环境的文档化方式特征”处理构造）和符合（但不是严格符合） ) C 程序可能会利用这些扩展。虽然名义上需要实现来生成响应某些此类构造的诊断，但无条件输出的实现将满足这样的要求：“警告 - 此实现不会打扰生成作者认为愚蠢的诊断（除此之外一）”，程序员可以自由地忽略他们认为愚蠢的任何诊断。
重要的是要认识到许多实用且有用的 C 程序利用了被广泛支持但并非普遍支持的有用结构。如果委员会试图将无法支持此类结构的平台描述为有缺陷的实现，那么这些平台的制造商就会拒绝它。如果它被描述为依赖这种结构的不合格程序，它就会被编程社区彻底拒绝。因此，作为一种妥协，它为程序定义了一个“严格符合”类别，该类别足够狭窄，以至于未能满足它很少被视为缺陷，