为什么使用严格一致的程序和一致的实现并不能保证绝对的可移植性？
Why does the use of strictly conforming programs and conforming implementations not ensure absolute portability?
C11, 4. 一致性，脚注 5（添加了强调）：
Strictly conforming programs are intended to be maximally portable among conforming implementations.
为什么strictly conforming programs && conforming implementations的组合导致便携性的分级（即最大）？
换句话说，为什么strictly conforming programs && conforming implementations的组合没有带来绝对的便携性？
确保绝对便携性的障碍/挑战是什么？
最大可移植性应该理解为一种保守的措辞。严格一致的程序应该在任何一致的实现上具有相同的可观察行为。
然而，可移植性可能不是 绝对的，因为对于标准的某些特定部分，某些实现可能是错误的。一个例子是可选部分，如果选项 is/is 未实现，则应声明特定常量。并且选项存在或不存在，但常量不存在......或者实现可以混合版本符合：它仅完全符合标准的非常旧版本并且除了一些细节外，几乎与上一个版本一致。或者存在有关标准的缺陷但尚未修复。不幸的是，许多现实世界的实现都属于这些类别，因此应该在每个 符合 实现上都能正常工作的好程序在常用实现上仍然存在问题。
C 标准涵盖托管和独立实现。两者之间没有（也可能）没有“绝对可移植性”。特别是对于托管实施，严格的合规性保证了可移植性，根据相同的 Conformance 部分 (C11 4.5-6):
A strictly conforming program shall use only those features of the language and library specified in this International Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.
The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program in which the use of the features specified in the library clause (clause 7) is confined to [...]
[ EDIT ] 正如 @Nate Eldredge 在下面的评论中指出的那样，符合要求的（托管）实现“ 应 接受 任何严格符合的程序”并不等于保证它将“能够 翻译和执行”相同的严格符合的程序。
这是因为 5.2.4 Environmental Limits 部分列出了一些最小限制，但只要求“实施应能够 翻译并执行至少一个包含至少一个实例的程序 以下每个限制”。
换句话说，即使严格遵循 4.5 and does "not exceed any minimum implementation limit", there is still no guarantee by the letter of the C law that the implementation will be able to succesfully compile and run it. As @Jerry Coffin put it in this answer 相关问题的程序：““hello world”程序不严格遵循 ”。
或者，正如 Derek M. Jones 在新 C 标准中评论的那样：
The topic of a perverse implementation, one that can
successfully translate a single program containing all of these limits but no other program, crops up from
time to time. Although of theoretical interest, this discussion is of little practical interest, because writing
a translator that only handled a single program would probably require more effort than writing one that
handled programs in general.
因为不同的实现用于不同的目的，并且针对具有不同能力的不同平台，任何试图确定一类程序的所有实现都需要有意义地处理的尝试要么需要排除所有执行作业的程序一些实现将无法完成，或者被标记为不符合要求的实现，这些实现适用于许多但不是人们使用 C 编程语言完成的所有任务。
该标准的作者认识到，解决这个问题的最实际的方法是认识到，寻求为许多平台和目的设计高质量实现的人会寻求有效地处理比标准要求的范围更广的程序，并将对此类计划的支持视为标准管辖范围之外的实施质量问题。不幸的是，C89 和标准的所有更高版本的作者故意避免以任何可能暗示某些 C 实现在许多方面不如其他实现的方式表达这种意图。
这个问题的解决方案，如果它在政治上不是站不住脚的，将是标准指定程序可以指示他们可能需要从实现中获得的任何特殊内容的方法，并指定 (1) 符合规范的实现可能出于任何原因拒绝任何程序，尽管质量实现不应该不必要地这样做，并且 (2) 实现 必须 ，作为一致性的条件，拒绝任何他们不能 [=16] 的程序=]否则 以一致的方式处理。这将使一类程序成为可能，其含义将在所有平台上定义（即使在某些平台上可能不存在任何可以处理它们的实现），但它仍然可以利用并非普遍支持的能力。不幸的是，我不知道有什么方法可以引导标准朝那个方向发展。
C11, 4. 一致性，脚注 5（添加了强调）：
Strictly conforming programs are intended to be maximally portable among conforming implementations.
为什么strictly conforming programs && conforming implementations的组合导致便携性的分级（即最大）？
换句话说，为什么strictly conforming programs && conforming implementations的组合没有带来绝对的便携性？
确保绝对便携性的障碍/挑战是什么？
最大可移植性应该理解为一种保守的措辞。严格一致的程序应该在任何一致的实现上具有相同的可观察行为。
然而，可移植性可能不是 绝对的，因为对于标准的某些特定部分，某些实现可能是错误的。一个例子是可选部分，如果选项 is/is 未实现，则应声明特定常量。并且选项存在或不存在，但常量不存在......或者实现可以混合版本符合：它仅完全符合标准的非常旧版本并且除了一些细节外，几乎与上一个版本一致。或者存在有关标准的缺陷但尚未修复。不幸的是，许多现实世界的实现都属于这些类别，因此应该在每个 符合 实现上都能正常工作的好程序在常用实现上仍然存在问题。
C 标准涵盖托管和独立实现。两者之间没有（也可能）没有“绝对可移植性”。特别是对于托管实施，严格的合规性保证了可移植性，根据相同的 Conformance 部分 (C11 4.5-6):
A strictly conforming program shall use only those features of the language and library specified in this International Standard. It shall not produce output dependent on any unspecified, undefined, or implementation-defined behavior, and shall not exceed any minimum implementation limit.
The two forms of conforming implementation are hosted and freestanding. A conforming hosted implementation shall accept any strictly conforming program. A conforming freestanding implementation shall accept any strictly conforming program in which the use of the features specified in the library clause (clause 7) is confined to [...]
[ EDIT ] 正如 @Nate Eldredge 在下面的评论中指出的那样，符合要求的（托管）实现“ 应 接受 任何严格符合的程序”并不等于保证它将“能够 翻译和执行”相同的严格符合的程序。
这是因为 5.2.4 Environmental Limits 部分列出了一些最小限制，但只要求“实施应能够 翻译并执行至少一个包含至少一个实例的程序 以下每个限制”。
换句话说，即使严格遵循 4.5 and does "not exceed any minimum implementation limit", there is still no guarantee by the letter of the C law that the implementation will be able to succesfully compile and run it. As @Jerry Coffin put it in this answer 相关问题的程序：““hello world”程序不严格遵循 ”。
或者，正如 Derek M. Jones 在新 C 标准中评论的那样：
The topic of a perverse implementation, one that can successfully translate a single program containing all of these limits but no other program, crops up from time to time. Although of theoretical interest, this discussion is of little practical interest, because writing a translator that only handled a single program would probably require more effort than writing one that handled programs in general.
因为不同的实现用于不同的目的，并且针对具有不同能力的不同平台，任何试图确定一类程序的所有实现都需要有意义地处理的尝试要么需要排除所有执行作业的程序一些实现将无法完成，或者被标记为不符合要求的实现，这些实现适用于许多但不是人们使用 C 编程语言完成的所有任务。
该标准的作者认识到，解决这个问题的最实际的方法是认识到，寻求为许多平台和目的设计高质量实现的人会寻求有效地处理比标准要求的范围更广的程序，并将对此类计划的支持视为标准管辖范围之外的实施质量问题。不幸的是，C89 和标准的所有更高版本的作者故意避免以任何可能暗示某些 C 实现在许多方面不如其他实现的方式表达这种意图。
这个问题的解决方案，如果它在政治上不是站不住脚的，将是标准指定程序可以指示他们可能需要从实现中获得的任何特殊内容的方法，并指定 (1) 符合规范的实现可能出于任何原因拒绝任何程序，尽管质量实现不应该不必要地这样做，并且 (2) 实现 必须 ，作为一致性的条件，拒绝任何他们不能 [=16] 的程序=]否则 以一致的方式处理。这将使一类程序成为可能，其含义将在所有平台上定义（即使在某些平台上可能不存在任何可以处理它们的实现），但它仍然可以利用并非普遍支持的能力。不幸的是，我不知道有什么方法可以引导标准朝那个方向发展。