8.1 読者の見つけたのはバグか?

読者が、果たしてバグを見つけたのかどうか判らない場合のために、 以下に指針を示す。

• コンパイラが致命的なシグナルを受けたなら、入力がどんなものであろうと、 それはコンパイラのバグである。信頼性のあるコンパイラは決して落ちたりしない。
• もしコンパイラがアセンブリコードとして正しくないコードを生成したなら、 入力がなんであれ(asm 文を除いては)、コンパイラが通常アセンブラの 実行を抑止するエラー(単なる警告ではいけない)を報告しない限り、 それはコンパイラのバグである。
• コンパイラが、アセンブリコードとしては有効であるが、入力ソースコードを 正しく実行しないコードを生成したなら、それはコンパイラのバグである。

  だが、この場合、二重にチェックして確認をして欲しい。 GNU C と旧来の C との間の非互換性に遭遇した可能性もあるからである (see section GCC の非互換性)。 この非互換性はバグであるとも 考えられるが、役に立つ機能であるためには避けられない結果である。

  あるいは、読者のプログラムの動作が未定義かもしれない場合は、 別の C コンパイラや C++ コンパイラを使うと望みの結果を与える 可能性も出てくる。

  例えば、多くのコンパイラでは最適化を行わない場合、関数の最後で、 ‘return x;’ と書く代わりに ‘x;’ と書くことができ、 結果は変わらない。だが、関数の値は return を 省略した場合は未定義である。GCC で違った結果が出てもそれは バグではない。

  インクリメント演算子を二つ使った式、例えば f (*p++, *p++) の ような式でも、良く問題が発生する。読者が以前使っていたコンパイラでは、 この式が読者の意図どおりに解釈されたかもしれない。GCC は別の解釈を するかもしれない。どちらのコンパイラも間違っていない。問題は読者の コードにある。

  エラーの起こるソース行を突き止めたなら、これらの事を確かめるのは 簡単なはずである。読者のプログラムが正しくて、うまく定義されているなら、 コンパイラのバグを見つけたことになる。

• コンパイラが正しい入力に対してエラーメッセージを出したなら、 それはコンパイラのバグである。
• コンパイラが正しくない入力に対してエラーメッセージを出さなかったら、 それはコンパイラのバグである。だが、「正しくない入力」と読者が 考えたものが、我々の考えでは「拡張機能」だったり「古い習慣のサポート」 だったりすることもありうるということに注意して欲しい。
• 読者が C コンパイラや C++ コンパイラ(あるいは Fortran や Objective-C)の経験を 積んだユーザなら、GCC を改良する提案はどんな場合でも歓迎する。

This document was generated using texi2html 1.78.