正しいソース
チームでプログラム開発している中で同じプログラムを使用
しているにも関わらず、あなたの作成したプログラム部分が
意図した動きをしない（バグがあるぞ）という連絡が入った。
会社ごとに機能を決めて開発していたが、自分の会社の環境
では問題なく動いていたので、プログラムのバージョンが古
いか環境等の違いなどではないかと軽い気持ちで連絡をくれ
た会社に乗り込み、状況を見せてもらった。
確かに、意図した動きをしない。（C++で作成していた時代）
そこで、インクルード等も含めたプログラムバージョン、開
発環境等を調べたが、自分の会社で正常に動作している環境
と全く同じであった。
見つけた。がしかし、自分の会社で開発しているソースと寸
分だがわず、全く同じソースであった。
マシンを立ち上げなおしたり、当該プログラムに影響を与え
そうな、DLLファイル等すべて調べたが、うまく動作しない。
トをはり、不具合！？調査をすることにした。
アセンブラにして顕在化した不具合
始して、すぐに原因がわかった。ある値が格納されるはずの
ので、アセンブラにしなければ、わからなかった。
が、どうしてそうなるのか、わからなかった。C++のソース
のデバッグと同様な（上記）調査をしたが、やっぱりわから
ない。相手からと、元々動いてないんじゃないのというよう
な視線がずきずき刺さってくるのがわかった。しょうがない
ので、連絡してきた相手を自分の会社に呼んで、疑いを晴ら
すしかないかと思い、何気なく、インクルードファイルの順
番を変えて、コンパイルしなおし、デバック！？してみたと
ころ、レジスタに意図した値が入るようになったではないか。
原因がインクルードファイルの順番かどうか、証明するため
うまくいかなかったときのインクルードファイルの順番に戻
し、コンパイルしたところ、不具合が再現した。
連絡してきた連中になぜかわからないが、インクルードファ
イルの順番が原因だということを説明し、正常な動作を確認
聞くが、こんなところで、その不具合にぶち当たるとは思わ
なかった。
くさいものにふたをするではないが、不具合を代替手段でカ
バーするというのはよくある話であるが、そのときは、その
方法がとれず、本当に困った。
どうしても解決できないプログラムの不具合に多数ぶちあた
ってきたが、そのうちのいくつかはコンパイラの不具合かも
と思うようになった。（ほんの数％か、それ以下とは思うが）
アセンブラは勉強しておいた方がいい
ため、そう容易には不具合が見つけられないと思うが、アセン
ブラは勉強しておいて、損はないのではないか。
