^^;;;)際に、それに関係するトラブルの消耗戦にはまり込んだ際に泥縄で読んだ本です。系にあがったことによる振る舞いの変化でした。起因する(と思われる)超難解トラブルの対策目的には大変ありがたい本でした。ちなみに書評者御本人も理解されてらっしゃるようで、コンパイラをいじろうかという目的の人だと本読んでも仕方ない旨を書かれていますが、全くその通りというか、もう4半世紀以上前のまだ私が新人で、自社計算機のためにCコンパイラを作るプロジェクトに配属され、当時日本語で(英語でも?)ほぼ唯一の教科書だったカーニハン・リッチーを読んでいて「そんなバカ本読んでてどうすんのよ!(言語仕様書よみなさいよ!)」と課長にしかられたのも懐かしい思いでです。プロがそんな本読んでていいのか!読むにせよ少しは恥ずかしいという後ろめたさを感じた上で読め!そしたら机の上になんか置けなくて引き出しに隠す筈だ!って感じで。フロー解析の結果を流用して作ろうと思い立って触り始めて「これは触ると障りがある」と気づいて挫折した過去があります。つかわれているんじゃないでしょうか。バージョンアップ時に構造体のパディングの方式が変わる等)が起きてしまうと、もちろんコードを追っかけているだけではなにもわからず、デバッグしてもこっちでは正しい値がはいっているのにあっちではへんな値で、あれ、誰が壊したの?と、まったく不可解な現象になってしまい大惨事です。いう時はもう、コンパイラの仕組み、特にコードを生成する仮定の理解とその変更が及ぼす原因を理解した上で、呼び出し元や呼び出し先(これらは得てして他社分担だったりします)まであわせてデバッグできる強力な協力関係がないと問題が解決しません。全体を短時間で俯瞰する目的に大変役に立ちました。私見ですが、こういう問題は、型がコンパイル時に決まってしまう静的な言語の、普段の便利さを裏返したいざとなったときの怖さでもあるように思います。動的な言語で、型がポインタではなくハッシュで表現されている場合、その解釈も実行時にきまるので、前述のような「構造体のパディング」の解釈が、そのライブラリが何時翻訳されたかで変わってしまうような、つまり実行時に解釈がバラバラになってしまうような問題も発生しないので。型チェックもしてくれないで単に「エラーです」とだけ言ってる現状は逆の意味で困った問題だとおもうのですが。知識を一気に大量に脳にインプットして、あふれかけた脳みそを振り回さないと問題解決のアイデアはでてこないですね。空の頭でいくら考えても禅問答のように抽象的になってしまいます。ページは大変有益でした。懐かしい石の名前もいまではとてもノスタルジックで(もしかしてまだどこかで現役の石でしたらごめんなさい)。