c - 使用过时的 C 编译器是否存在安全风险？

Question

我们在生产中有一些没有人关心的构建系统，这些机器运行 GCC 的旧版本，如 GCC 3 或 GCC 2。

而且我无法说服管理层将其升级到更新的版本:他们说，“如果没有坏，就不要修理它”。

由于我们维护着一个非常古老的代码库(写于 80 年代)，因此此 C89 代码在这些编译器上编译得很好。

但我不确定使用这些旧东西是个好主意。

我的问题是:

使用旧的 C 编译器会损害编译程序的安全性吗？

更新:

Visual Studio 2008 为 Windows 目标构建了相同的代码，而 MSVC 尚不支持 C99 或 C11(我不知道更新的 MSVC 是否支持)，我可以使用最新的在我的 Linux 机器上构建它海湾合作委员会。因此，如果我们只是加入一个较新的 GCC，它可能会像以前一样构建得很好。

Answer 1

实际上我会反驳。

在许多情况下，C 标准未定义行为，但很明显在给定平台上使用“哑编译器”会发生什么。允许有符号整数溢出或通过两种不同类型的变量访问同一内存等情况。

最新版本的 gcc(和 clang)已经开始将这些情况视为优化机会，而不关心它们是否会改变二进制文件在“未定义行为”条件下的行为方式。如果您的代码库是由将 C 视为“可移植汇编程序”的人编写的，那将是非常糟糕的。随着时间的推移，优化人员在进行这些优化时已经开始关注越来越大的代码块，这增加了二进制文件最终做一些不同于“由愚蠢的编译器构建的二进制文件”会做的事情的机会。

有一些编译器开关可以恢复“传统”行为(-fwrapv 和 -fno-strict-aliasing 用于我上面提到的两个)，但首先您必须了解它们。

虽然原则上编译器错误可能会将合规代码变成安全漏洞，但我认为这种风险在宏伟的计划中可以忽略不计。