もう一ヶ月くらい前の話ですが、VB で作成したツールにバグがあるとパートナーさんから指摘されました。
親切にもデバッグまでやってくれたらしく「○○のカウントを取得する部分で、こちらの環境では 352321536 という大きな値が取得されてしまうのでオーバーフローを起こしているようです。境界チェックのコードを追加してください」とのこと。

えーと。このカウントっていうのはデータベースのテーブル数みたいなもので。いくらなんでもそれはないだろ、と思ったわけですが。

さて、バグの原因に見当がつくでしょうか？



翌日、バグ対応のために客先に向かいました。
実際動かしてみると確かに 352321536 とそういう値が取得されたわけですが。

だいたい見当はついていたので、352321536 という数字を calc.exe で 16 進数に変換してみました。
0x15000000 でした。ああ、やっぱり。

有名なバイトオーダーの問題です。テスト用環境ではサーバマシンに Windows（というか Intel 系のマシン）を使っていて、客先では AIX（よく知らないのですが、非 Intel 系）を使っていたのでした。
前者はリトルエンディアン、後者はビッグエンディアンと。
実際にこの問題に遭遇したのは初めてだったので、結構新鮮でしたが。

結局ミドルウェアの API に「バイトオーダーを自動調整する」みたいなオプションがあったので、それで解決できました。

えーと・・・何が言いたいかというと。
「とりあえず 16 進数に」みたいなのって大切だなと思いまして。
何かの実行中によくわからない数字がぽっと出てきた場合は、とりあえず 16 進数に変換する癖をつけましょう。

で、そのためには ASCII コードのだいたいのイメージもつかんでおく必要があるかな、と。
1094861636 いう値がいきなり出てきたとして、16 進数に変換すると 0x41424344 だとわかっても、解決できないと困るので。

0x09 = TAB

0x0a = LF

0x0d = CR

0x20 = SPACE

0x30〜 = 0〜9

0x41〜 = A〜Z

0x61〜 = a〜z

くらいは頭に入れておきたいところです。

0x41424344 は "ABCD" なので、この場合だと文字列がバッファオーバーフローを起こしていないか、とかそういうことを疑うことになりますかね。