[ < ] | [ > ] | [ << ] | [ Up ] | [ >> ] | [Top] | [Contents] | [Index] | [ ? ] |
この節で述べる問題は、残念なことだが、実際的な回避方法が見つかっていない。
これは、GCC の最適化により変数そのものが消えてしまうことがあるためである。 このような「あったはずの」変数の値を計算する方法をデバッガに 知らせる術はないし、そういうことが出来たとして、それが望ましいことかどうかは はっきりしない。このため GCC は、デバッグ情報を書き出すときに、 消去された変数については何も情報を出さないのである。
このため、最適化を行なったときは、実行形式とソースコードの 間に一致しない点があることをある程度予想しておかなくては成らない。
int foo (struct mumble *); struct mumble { … }; int foo (struct mumble *x) { … } |
このコードは実際に間違っている。なぜなら、プロトタイプの中の
struct mumble
のスコープは、それを含んでいる引数リストに
限られるからである。それは、直後にファイルスコープで定義されている
struct mumble
は参照していないのである。この二つは、
別々のスコープにある、名前は同じだが関係の無い二つの型なのである。
だが、foo
の定義の中では、ファイルスコープの型が使われる。
継承により利用可能になるからである。
こうして、関数定義とプロトタイプが一致しないので、エラーになる。
この振る舞いは馬鹿々しいと思えるかもしれないが、これが
ANSI 規格が規定していることなのである。
正しく動作するようにするのは簡単で、struct mumble
の定義を
プロトタイプの上に持っていけば良い。
上に示したような例のエラーを避けるためだけに、ANSI C との互換性を
損なう価値はない。
アクセスされるメモリ量を制御したければ、揮発性オブジェクトを使用し、 ビットフィールドは使わないようにすること。
新しいシステムヘッダファイルがインストールされた場合は、
自動的に正しいヘッダファイルに更新するしかけにはなっていない。
その場合、GCC を再インストールして新しいヘッダファイルを
修正する必要がある。細かく言うなら、構築を行なったディレクトリに
移動し、‘stmp-fixinc’ と ‘stmp-headers’ というファイルと
include
というディレクトリを削除し、もう一度
‘make install’ を行なう。
double
よりも数ビット分高い精度を保持しているためである。
コンパイルされたコードは、都合に合わせて値をメモリと浮動小数点
レジスタの間でやり取りする。そして、値をメモリに移動すると
その値が切り詰められることになる。
この問題は、‘-ffloat-store’ オプションを使えば部分的に 回避できる(see section 最適化オプション)。
可変数引数を使う方法として、ANSI 規格の ‘stdarg.h’ を使うように コードを書き換えて、呼出し時のスコープ内にプロトタイプ宣言を 置くようにすれば全てうまくいく。
This document was generated
using texi2html 1.78.