C99是否与C89向后兼容？
我习惯了旧式C和最近才开始探索c99function。 我只有一个问题：如果我在我的程序中使用c99，使用gcc的c99标志并将其与之前的c99库链接，我的程序是否会成功编译？
那么，我应该坚持旧的C89还是进化？
我相信他们在这方面是兼容的。 只要您正在编译的内容不会踩到任何新的好东西。 例如，如果旧代码包含enum bool { false, true }; 那你就麻烦了 作为一个类似的恐龙，我正在慢慢拥抱C99的美妙新世界。 毕竟，它现在已经潜伏了大约10年;）
你应该进化。 谢谢收听 ：-）
实际上，我会扩展它。
你是对的，C99已经存在了很长一段时间。 您应该 （在我看来）将该标准用于遗留代码以外的任何其他内容（您只修复错误而不是添加新function）。 遗留代码可能不值得，但您应该（与所有业务决策一样）进行自己的成本/收益分析。
我已经确保我的新代码与C1x兼容 – 虽然我还没有使用任何新function，但我会尽量确保它不会破坏。
至于要注意什么代码，标准的作者非常重视向后兼容性。 他们的工作不是设计一种新语言，而是编纂现有的做法。
他们目前所处的阶段使他们在更新语言方面有更多的自由，但他们仍然遵循希波克拉底誓言的输出：“首先，不要伤害”。
通常，如果您的代码被新标准破坏，编译器将被迫告诉您。 因此，简单地编译代码库将是一个很好的开始。 但是，如果您阅读C99基本原理文档 ，您会看到“安静更改”这一短语 – 这是您需要注意的。
这些是编译器中的行为变化，您不需要了解这些变化，如果您的应用程序开始表现奇怪，可能会引起很多焦虑和咬牙切齿。 不要担心“c89中的安静变化” – 如果它们是一个问题，你就会被它们咬伤。
顺便说一下，这份文件是一本很好的读物，可以理解为什么实际标准会说出它所说的内容。
恭敬地： 尝试并找出答案。 🙂
但是，请记住，即使您需要修复一些微小的编译差异，向上移动也许值得。
如果您没有违反显式C99function，c90代码将与另一个先前的c99库一起工作。
但是在C89中有一些基于dos的库，这肯定是行不通的。
C99非常灵活，所以随意迁移:-)
C库之间的调用约定在很大程度上没有改变，事实上，我不确定它有没有。
此时操作系统严重依赖于C调用约定，因为C API往往是操作系统各部分之间的粘合剂。
因此，基本上答案是“是的，二进制文件将向后兼容。不，当然，使用C99function的代码以后不能用非C99编译器编译。”
它旨在向后兼容。 它规范了许多供应商已经实施的扩展。 有可能，甚至可能，编写良好的程序在使用C99编译时不会有任何问题。
根据我的经验，重新编译一些模块而不是其他模块来节省时间……浪费了很多时间。 通常有一些容易被忽视的细节需要新的编译器才能使它兼容。
C89标准的一些部分是模糊编写的，并且根据如何解释关于指针类型和它们访问的对象的规则，标准可以被视为描述两种非常不同的语言之一 – 一种其中语义function更强大，因此可用于更广泛的领域，其中一个允许更多的机会进行基于编译器的优化。 C99标准“澄清”规则，明确表示它不会强制要求与前一种语言兼容，即使它在许多领域都受到压倒性的支持; 它还将某些在C89中定义的内容视为未定义，但仅仅因为C89规则编写得不够精确以禁止它们（例如，在目标具有堆持续时间的情况下使用memcpy进行类型惩罚）。
因此，C99可能与其作者认为由C89描述的语言兼容，但与大多数C89编译器在整个20世纪90年代处理的语言不兼容。
某些C89function无效C99
可以说，这些function仅出于历史原因而存在，不应在现代C89代码中使用，但确实存在。
C99 N1256标准草案前言第5段将C99与旧版本进行了比较，并且是开始搜索这些不兼容性的好地方，即使它具有比限制更多的扩展。
隐式int返回和变量类型
Lutz在评论中提到，例如以下是有效的C89：
static i; f() { return 1; }
但不是C99，你必须写：
static int i; int f() { return 1; }
这也排除了在C99中没有原型的调用函数： C89，C90或C99中的所有函数都需要原型吗？
n1256说：
删除隐式int
返回无表达式的非void函数
有效C89，无效C99：
int f() { return; }
我认为在C89中它返回一个实现定义的值。 n1256说：
在返回值的函数中不允许返回表达式
具有负操作数的整数除法
- C89：舍入到实现定义的方向
- C99：舍入为0
因此，如果您的编译器舍入为-inf ，并且您依赖于该实现定义的行为，则您的编译器现在被迫在C99上破坏您的代码。
https://stackoverflow.com/a/3604984/895245
n1256说：
可靠的整数除法
Windows兼容性
一个主要的实际问题是能够在Windows中编译，因为微软不打算太快实现C99 。
这就是为什么libgit2 限制允许C99function的原因 。