昨日のこの記事
書いた直後から、私のブログ始まって以来のケタ違いの脅威のアクセス数、 はてブ 数、リツート、いいね等々をいただき、注目度の高さにびっくりしています。
ブコメ の中にも多く書かれていますし、また、コメント欄にてあけぼのさんにも詳細に解説していただいておりますが、ほぼ間違いなく理由はそれでしょう。
ちなみにドコモへのWEBからの問い合わせではすが、
My docomo のIDでログインして質問送ったのに、お客様情報保護の観点から云々言われてメールでは回答は得られませんでした。
時間の取れた時にでも151に言って見る予定です。
さて、理由ですが、内部処理の問題ですね。
エンジニアでもあり昔はソフトも書いてた自分ですが気づきませんでした。ぉ恥ずかしい。。。
65536とか1600万とかなら気づいたかと思いますが、42億はダメだ。。。
古い人間ってことですね。。。
コメントが非常にわかりやすいので改めて言うまでもありませんが、一応書いてみます。
もし間違っていたらご指摘いただけると幸いです。
32bitの変数の場合、取り得る数字の範囲は
unsignedの場合は、0000_0000H(0)～FFFF_FFFFH(4,294,967,295)
signedの場合は、8000_0000H(-2,147,483,648)～7FFF_FFFFH(2,147,483,647)
となります。
今回の場合は、まずはファミリー割引料として-1040円ですから
-1040(Dec)→FFFF_FBF0(Hex)で格納されていることになります。
これをsignedでなくunsignedで扱ってしまうとFFFF_FBF0(Hex)→4,294,966,256(Dec)となり明細書の値とドンピシャとなります。
同様に、eビリング割引料の-20円も
-20(Dec)→FFFF_FFEC(Hex)
→4,294,967,276(Dec)
となり、これまた明細書の値とドンピシャってことですね。
まぁ確かにプログラム作成上ではよくあるバグかもしれませんが、天下のドコモでしかも請求書とか明細書っていうお金が絡んでくるところでこのようなバグがあるまま運用されているってのはちょっと信じられません。
今まではちゃんと動いてたわけですし。
顧客によってプログラムが違うとは思いにくいので、おそらく私以外にも同様な方もいらっしゃるかと思いますが、合計金額には影響が無いようですので気づきにくいのかもしれませんね。
ご指摘いただいたみなさんありがとうございました。
コメント