我们在生产中有一些无人关心的构建系统，这些机器运行GCC的古老版本，比如GCC 3或GCC 2.
我也无法说服管理层将其升级到最近的版本:他们说，"如果没有坏掉，就不要修复它".
由于我们维护了一个非常古老的代码库(写于80年代)，所以这段C89代码在这些编译器上编译得很好.
但是我不确定用这些旧东西是不是个好主意.
我的问题是:
使用旧的C编译器会损害编译程序的安全性吗？
更新:
同样的代码也是由Visual Studio2008 for Windows target构建的，而msvc目前还不支持C99或C11(我不知道更新的msvc是否支持)，我可以使用最新的GCC在我的linux机器上构建它.所以，如果我们换一辆新的GCC，它可能会造得和以前一样好.
实际上，我的观点正好相反.
在很多情况下，C标准没有定义行为，但在给定平台上使用"哑编译器"会发生什么，这是显而易见的.例如允许有符号整数溢出或通过两种不同类型的变量访问同一内存.
gcc(和clang)的最新版本已经开始将这些情况视为优化机会，而不管它们是否会改变二进制文件在"未定义行为"条件下的行为.如果你的代码库是由那些把C当作"可移植汇编程序"的人编写的，这是非常糟糕的.随着时间的推移，在进行这些优化时，优化人员已经开始关注越来越大的代码块，这增加了二进制文件最终执行"由愚蠢的编译器构建的二进制文件"之外的操作的可能性.
有一些编译器switch 可以恢复"传统"行为(我上面提到的两个是-fwrapv和-fno-strict-aliding)，但首先您必须了解它们.
虽然原则上编译器错误可以将兼容的代码转换成安全漏洞，但我会认为，在这个宏伟的计划中，这种风险是可以忽略的.