「Visaカードで 23,148,855,308,184,500ドルの請求発生、原因はプログラムエラー」記事へのコメント

限度額が反映されないのは

[Anonymous Coward]

BCDコードを文字列と誤認してスペースをパディングするコードを書いたのではないかって意見が一番もっともらしい気がします。
それならば、金額計算段階ではなく表示の直前で値が壊れたので限度額計算時は正常だったから限度額で拒否されることは無かった、と理解できます。

そうすると(10進数のパック状態を誤認する時点でそれを期待するのも酷ですが)表示のために加工した値で元の値を上書きする筈は無いので、問題点を表示部分だけに限定できそうです。
実は表示がおかしいだけでコアのシステムは正規の金額で平常運転していた可能性は無いでしょうか。

データの出力は利用者が希望する体裁ごとに表示加工するプログラムが異なりますから発症者が有る程度限定されてくる理由になりますし、引き落とし処理に直接関係しないためチェックがゆるかったのではないかと言う推測も成り立ちます。

Re:

[coffe_ata (31369)]

勘定なので、BCD表現を含む固定小数点数というのは順当だと思います。
ただ、やっぱり、請求するときに起きてるように思います。

• 0をスペースでパディングしていた(もしくは、してしまった)
• 8バイト長整数が必要な場面で8バイト長固定小数点数を直接入れてしまった

この二本立てじゃないでしょうか。
前者は微妙に思えますが、まあ、どうでしょうね。

Re:

[Anonymous Coward]

> 勘定なので、BCD表現を含む固定小数点数というのは順当だと思います。
> ただ、やっぱり、請求するときに起きてるように思います。

まだそんなこと言ってんのかバカ

Negative Balance Feeが請求されているんだぞ

Re:

[Anonymous Coward]

$23,148,855,308,184,500.00が正しく処理されて、Negative Balance Feeが請求されたということではないんですか？

Re:

[Anonymous Coward]

> $23,148,855,308,184,500.00が正しく処理されて、Negative Balance Feeが請求されたということではないんですか？

違うよ。GIGOというものがあってね
ここからわかることは

1. 請求額の計算かそれより前の処理のどこかで、内部表現に16進数が使われている可能性が高い(BCDや文字列ではなく)
2. 1と同じかそれより前の処理のどこかで、ゴミデータが紛れ込んだ
3. 1の数字は2のゴミかその加工された子孫だろうが、そのものではないかもしれないし、Negative Balance Feeの根拠となったゴミとは祖先を共通とする異なるゴミかもしれない。

わからないことは
・それ以外の処理については外部からは全くなにもわからない。内部表現などもってのほか。

Re:限度額が反映されないのは

[coffe_ata (31369)]

なるほど、エラーのせいで、買い物していないゴミデータが請求されていたということですね。
買ってもいないのに請求は予想外でした。(#1607508) [srad.jp]からするとそうなのかも知れませんね。

# $46.88を8バイト長でーとか考えてたんですが、
# 単純なゴミ入れゴミ出しだったということですね。