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