的TCS（技术勘误或技术校正）应被视为相应的碱标准的一部分。所以，你真的有4个可能的标准来处理：
- ISO/IEC 9899：1990加TC。
- ISO/IEC 9899：1990 + AM1（实际上9899：1995）加上TC。
- ISO/IEC 9899：1999加上TC。
- ISO/IEC 9899：2011
为C90修订1中添加宽字符和多字节字符集的新报头和功能，所以它包含真正的新标准的材料。技术勘误解决了标准措辞中的问题，澄清了需要澄清的问题，并纠正了文档中的技术错误。
所以，我建议这四个模式就足够了：
-std=c90-std=c95-std=c99-std=c11
或者，如果我们要支付注意导致Y2K问题的错误N：
-std=c1990-std=c1995-std=c1999-std=c2011
（这样做的好处是，最新标准的编号最大一次！）
对于独立实现，有在四个头被要求几点不同：
<stddef.h><limits.h><float.h><stdarg.h>
有一个额外的宏/功能，va_copy()，添加到C99中的<stdarg.h>。
修正
我只是检查C99的相关部分，并有一些在C99一个独立的实现需要额外的头：
§4一致性
¶ 6 合规执行的两种形式是托管和独立式。 托管实施的符合 应接受任何严格符合的程序。一个符合 独立实现应接受任何严格符合程序，不 使用复杂的类型，并在其中使用的库条款 （第7章）中指定的功能仅限于标准头<float.h>， <iso646.h>的内容， <limits.h>,<stdarg.h>,<stdbool.h>,<stddef.h>和 <stdint.h>。符合的实现可能有扩展（包括额外的 库函数），前提是它们不会改变任何严格符合的程序的行为。 3）
3）这意味着一个符合标准的实现储备没有标识比明确 本国际标准中保留的其他。
§5.1.2.1独立式环境
¶1在独立环境中（其中，C程序执行可发生而无需操作系统的任何 益处），名称和功能的类型调用程序 启动是实现定义的。除了第4条所要求的最低限度设置以外，独立式 程序可用的任何图书馆设施都是实施定义的。
¶2独立环境中程序终止的影响是由实现定义的。
否则，主要的变化发生在C99语言的核心 - 比如新类型（long long），新的初始化符号，和沃拉斯，等等。从这个角度来看，AM1（C95）没有改变独立实现的任何东西（除非添加二元符号），因为主要变化是在新的头文件中，而独立实现中并不需要这些新头文件。
托管实现面临更多问题，因为库支持在C90和C99之间进行了相当广泛的修改。
没有任何的改变对独立实现打破向后兼容性？换句话说，如果我拥有一个严格独立的C {1990,1995,1999}符合计划，它是否必须按照预期符合C11的实施进行编译和工作？
我不知道任何向后兼容性问题独立，而不是托管实现。使用C99时，“隐含的int”规则正式消失 - 您应该在使用它们之前声明函数，返回类型应明确为int（例如，简单的main()不再正式有效;您应该编写int main()或更好，int main(void)等）。但是这些是C90（C95）和C99之间的一般变化 - 不是独立实现所特有的。 （是的，我知道一个独立实现不需要函数main()作为起点。）如果你的代码是'好的'，并且在使用之前有函数声明或定义了原型，并且没有隐式的类型（并且定义了所有的函数强烈建议使用原型符号），那么C90独立程序的好处是C99或C11。
独立实现的任何更改是否会破坏向后兼容性？换句话说，如果我拥有一个严格独立的C {1990,1995,1999}符合计划，它是否必须按照预期符合C11的实施进行编译和工作？ – 2011-12-30 18:41:16