[解決済み] 古いCコンパイラを使うのはセキュリティリスクか？

質問

私たちは、誰も気にしない生産中のいくつかのビルドシステムを持っており、これらのマシンはGCC 3やGCC 2のような古いバージョンのGCCを走らせています。

そして、より新しいものにアップグレードするように管理者を説得することができません。彼らは、「壊れていないなら、直さないこと」と言います。

私たちは非常に古いコード ベース (80 年代に書かれたもの) を保守しているので、この C89 コードはこれらのコンパイラーで問題なくコンパイルできます。

しかし、これらの古いものを使用することが良い考えであるかどうかはわかりません。

私の質問です。

古い C コンパイラを使用すると、コンパイルされたプログラムのセキュリティが損なわれることがありますか？

UPDATEしてください。

同じコードが Windows ターゲットの Visual Studio 2008 によってビルドされ、MSVC はまだ C99 または C11 をサポートしておらず (新しい MSVC がサポートしているかどうかは知りません)、最新の GCC を使用して私の Linux ボックスでビルドすることができます。ですから、もし私たちがより新しい GCC をドロップすれば、おそらく以前と同じようにうまくビルドできるでしょう。

どのように解決するのですか?

実は、私はその逆を主張したいのです。

C 標準では動作が定義されていないけれども、与えられたプラットフォーム上で "dumb compiler" によって何が起こるかが明らかであるようなケースが数多く存在します。例えば、符号付き整数のオーバーフローや、2 つの異なる型の変数を使用して同じメモリにアクセスするようなケースです。

最近のバージョンの gcc (および clang) は、これらのケースを最適化の機会として扱い始め、バイナリが "undefined behaviour" 条件でどのように動作するかを変更しても気にしないようになっています。 これは、Cを移植可能なアセンブラのように扱っていた人たちが書いたコードベースであれば、非常にまずいことです。時間が経つにつれて、オプティマイザーはこれらの最適化を行う際に、より大きなコードの塊を見るようになり、バイナリが「馬鹿なコンパイラーが作ったバイナリがやること」以外のことをするようになる可能性が高くなりました。

伝統的な動作を復元するためのコンパイラー スイッチがあります (上に挙げた 2 つのスイッチのうち、-fwrapv と -fno-strict-aliasing) が、まず、それらについて知っておく必要があります。

原理的には、コンパイラーのバグによって、準拠したコードがセキュリティホールになる可能性がありますが、私はこのリスクは物事の大筋において無視できるものだと考えています。