-
いやないか
http://dummy.cooom
-
銀行のシステムってCなの？
COBOLか、それを書き換えてJavaにしてると思ってた -
>>3
この障害箇所はデータ転送周りのプログラムじゃね -
sizeofでmallocしてなかったって事？
まああるある…か？ -
必殺３２ビットコンパイル！
-
ポインタサイズが２倍になるからな
そんでいて大したメリットは無いっていうでもセキュリティ関連でやらないといけないから
モチベーションは低い -
>>7
全銀手順でモチベ上がる人間いるのかよｗ -
テスト環境ないの
この馬鹿業界 -
再コンパイルのみでいきなり本番環境にリリースってすげーww
-
確かに言語仕様上は「int型」のサイズは固定ではないし、実際にほとんどの32bitコンパイラでは「int型」が16bitから32bitになったが、
実務で使われてる開発環境の中で「int型」を64bitにしてるコンパイラ見たことないわ -
やっぱりc言語って糞だわ
-
1円未満の誤差も許さないほど数字には厳しい金融システム開発なら
その辺考慮してそうなもんだけどな
と思ったらインデックステーブルか
直接のお金の部分ではないし気が抜けていたか -
64bit化でメモリー増えるぜ!!
命令が32bitのままで4GBまでしか使えません
止まりました！かな？
-
まあ32bitから64bitの移行でバグが出ないわけ無いから
これだけで収まったなら良くやったってレベルだよ
ただ並行運用の試験してれば防げたかもな -
64ビット化は業務的になんのプラスもないだろうし安く済ませたいだろうなあ
となるとテスト検証を削りたいだろうなあ -
起きたり起きなかったりのメモリリークならともかく
こういう非互換ってテストして動作確認しないものなの？ -
>>23
メモリ破壊なので気づかなかったんだと思う
ページ終端踏み外せばプロセスクラッシュしてくれるけど、
運良く/運悪く踏み外しても書き込めるメモリが割り当たってたんやろ -
>>23
事前テストの際に基盤環境までは再現していなかったらしい -
>>25
それってテストの意味無いよね…
しかも金融系システムでしょ… -
誰が悪いの
-
振り込みの桁が増えるバグにはならんかったん🥺
金額マシマシで振り込みとかにならず、うまく処理が止まる物なんやな
-
昔はintが１６ビットだったけど、当時はコンピュータがここまで発展すると思って無かったので
古いシステムではintの扱いがメチャクチャになっている -
Rustしか勝たん
-
C言語で作ってんの？
全銀ネットの障害原因、サーバの64ビット化によってint型のサイズが変わったことの考慮漏れか。あるあるだな
嫌儲
コメント