先日の全銀トラブルの原因、構造体サイズの手計算が原因だった!sizeof使おうよ、ガキじゃないんだからさ

サムネイル
1 : 2023/12/02(土) 11:16:21.18 ID:J6/vNn070

アホみたいな障害だな
http://dummy.cooom

2 : 2023/12/02(土) 11:16:29.74 ID:J6/vNn070
徳丸 浩 @ockeghem (2023/12/02 10:03:42)
昨日の「NTTデータ&全銀ネット 共同会見」を視聴していますが、例のトラブルは、構造体のサイズ計算を手でやっていて、「単体での計算は正しかったが、4つまとめると境界がずれた」趣旨が説明されているので、アライメントの考慮不足だったようです
動画→ https://www.youtube.com/watch?v=HOBfx3bRvGs&t=1098s
https://ohayua.cyou/tweet/1730754578570985646/ockeghem

[引用元] 徳丸 浩 @ockeghem (2023/10/17 10:30:31)
@kozawa sizeof(構造体)を手計算していたが、intのサイズが64ビットになって計算間違いが生じた…みたいな妄想は私もしましたw
https://ohayua.cyou/tweet/1714091486239981790/ockeghem

3 : 2023/12/02(土) 11:17:53.29 ID:xT5gQm2Y0
これはひどい
4 : 2023/12/02(土) 11:20:17.04 ID:igzP/f0k0
手計算するほうが面倒くさいのになんで?
6 : 2023/12/02(土) 11:23:53.22 ID:yS12Lx/vH
>>4
構造体のサイズ計算できる言語の経験がない人が上にいたとか、、、
エンディアンもそうだがこういう知識ない人の増えたのかな
31 : 2023/12/02(土) 12:18:18.22 ID:iZtJgSEm0
>>6
最新の技術のキャッチアップには余念がないのに
浮動小数点誤差すら知らない奴もいる

おっさんの頃だとこれは入門レベルの知識だったはずなのに

5 : 2023/12/02(土) 11:23:17.28 ID:scF7vvbn0
バッファオーバーフローしたの??
7 : 2023/12/02(土) 11:24:28.59 ID:wpkZ3wgY0
古い技術者は自分が初めて触ったシステムが絶対だと考え
新しいシステムになっても自分のやり方を変えない
8 : 2023/12/02(土) 11:25:17.90 ID:qnb0KjaK0
charとか混ってるとパディングされてサイズもオフセットも変って来るからな
16 : 2023/12/02(土) 11:33:25.37 ID:yS12Lx/vH
Javaは
int 32
long 64
でした
>>8あたりが正解じゃないかな
9 : 2023/12/02(土) 11:26:25.96 ID:yS12Lx/vH
というかintを64bitにする環境ってあるの?
過渡期にintが16bitと32bitがあった気がしたが
今はintは32bitが大半でしょ?
10 : 2023/12/02(土) 11:26:39.22 ID:pIRsK3aK0
銀行のシステムでC使うの?
CobolかJava使ってるのかと思ってた
12 : 2023/12/02(土) 11:29:17.31 ID:yS12Lx/vH
>>10
銀行系ではあるけど全銀の方なので各社の
電文だっけ?の吸収含めた中継システムで
確か新しい言語に置き換えてトラブルだったような
27 : 2023/12/02(土) 12:01:29.94 ID:igzP/f0k0
>>10
通信系だしCOBOLとかJavaあたりはまず使わんだろ
28 : 2023/12/02(土) 12:04:12.89 ID:gUHd6GdI0
>>27
ああ通信系ならCOBOLなんて使わんだろうなw
11 : 2023/12/02(土) 11:28:13.10 ID:D/8wAl5bH
chatGPTのがマシだな
13 : 2023/12/02(土) 11:32:13.81 ID:/OvHFv2Q0
C言語自体がミスを誘発するクソみたいな作りだろ
構造体もだしポインタもクソだし
14 : 2023/12/02(土) 11:32:36.98 ID:CD4RPpvt0
sizeof禁止なコーディングルールだったのかもしれんぞ
18 : 2023/12/02(土) 11:40:03.22 ID:D/8wAl5bH
>>14
バグを作る以外の目的が存在しないルールで草
15 : 2023/12/02(土) 11:33:13.07 ID:D/8wAl5bH
sizeof使わない意味が本気で分からんのだがマジでどんな世界なんだよ
20 : 2023/12/02(土) 11:44:51.78 ID:Jnf6PoVrr
>>15
知らないから
手で計算なんてめんどくさい、なんか楽な方法があるはずだ
とは考えず、知ってる範囲でめんどくさいこ頑張る奴はどこにでも一定数いる
17 : 2023/12/02(土) 11:39:53.70 ID:Jnf6PoVrr
処理系変わるたびにサイズ計算やり直すの?
19 : 2023/12/02(土) 11:43:08.24 ID:QWidoBSH0
何で業務アプリで未だにメモリ弄ってんの?
もっと安全な言語に変えられないの?
21 : 2023/12/02(土) 11:49:44.80 ID:gUHd6GdI0
金融機関ってだいたいCOBOLなんじゃないの?
22 : 2023/12/02(土) 11:50:23.91 ID:VhB1mV8I0
メモリいじってるよなこれ
23 : 2023/12/02(土) 11:50:39.91 ID:91BDiV/M0
この手の手計算というか決めうちは第一次オンライン第二次オンラインとかの
メモリが少なかった時代から引き継がれてる
謎技術の残滓とかなんでしょ
29 : 2023/12/02(土) 12:04:44.94 ID:igzP/f0k0
>>23
そのあたりの実装だと汎用機て動くアセンブラだろからsizeofなんて夢のような便利な仕掛けは無かったろうな
24 : 2023/12/02(土) 11:51:57.08 ID:ec9n30MYM
金融はもうHaskellとかF#とか宣言的に書くスタイルの言語で統一すればいいのに
なんで処理系意識しながら書く必要があるんだよ
25 : 2023/12/02(土) 11:55:06.96 ID:W+7r5Qoy0
Cなの?
26 : 2023/12/02(土) 12:00:37.53 ID:yS12Lx/vH
昔の仕様を引きずってそうなので
電文サイズとかガチガチのレガシーあって
それに合わせて手計算しろ!みたいなのありそう
30 : 2023/12/02(土) 12:14:15.84 ID:yS12Lx/vH
勘定系の記事読んでたらPL/IってCOBOLより古い言語扱いなのね

コメント

タイトルとURLをコピーしました