- - PR -
西暦2038年問題
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2004-02-09 16:48
ほむらです。
------- おばけ氏へ ># ワードサイズが64bitだと、intは4バイト、longは8バイト、となるのだろうか、、、 ワードはワードだと思いますよ。 BYTE,WORD,DWORD,QWORDになると思います。 ちなみに、int と書いた場合はCPUに対して最適なbitが割り当てられるようなので 16bitCPUならWORD 64bitCPUならQWORDになるのではないでしょうか? #アドレス境界とも言うかもしれない。 intで定義して変なデータはオーバーフローすることを前提として使っている場合 やばいことになりますね。 #ところで64bit intを使いたいと思ったら #long long intになる? >もはや、MyBigIntegerとかを定義するしかないかと。 Windowsで4GB以上のファイルを扱う場合似たようなことが必要だった気がします。。。 | ||||||||
|
投稿日時: 2004-02-10 01:09
(long が32ビットとすると)そうなんですが、それをやったときに まずいことが起こるコードが紛れ込んでないかチェックするのが 大変でしょうなあ... [ メッセージ編集済み 編集者: ぽんす 編集日時 2004-02-10 01:11 ] | ||||||||
|
投稿日時: 2004-02-10 08:11
どんなに、未来のことを想定しても、
あらゆる場合に対処するのは、不可能でしょう。 やはり、事後対策をどれだけ速やかにできるかに尽きると思います。 | ||||||||
|
投稿日時: 2004-02-10 09:04
(確認)…あれ?ホントだ。あれれ?なんで「12桁」にしたんだろう? えっと、Oracleは34桁か36桁扱えるんですね。けれども、.NET F/Wではそんなに扱えないので桁を削ったのですが、あれ?なんで12桁なんだろう?「14桁だから、安全マージン取って12桁」と思っていたのだが? | ||||||||
|
投稿日時: 2004-03-03 11:27
詳細が日経システム構築に載りましたね。 まさに、足して2で割っていたという、、、 統合ATMが陥った“テスト不足”の落とし穴 [ メッセージ編集済み 編集者: おばけ 編集日時 2004-03-03 11:33 ] | ||||||||
|
投稿日時: 2004-03-08 12:21
KDDIは誤請求だそうで。。。
[2038年問題のチェック漏れで、KDDIが誤請求] http://itpro.nikkeibp.co.jp/free/NC/NEWS/20040305/140989/ | ||||||||
|
投稿日時: 2004-03-08 14:11
余談でし〜
昔々。 charが9ビット、shortとintとlongがすべて4バイト、ってマシンが 実在したそうです。 一応 ・charのビットは「最低8」としか言及されていない ・shortは「intと等しいか、或いは小さい」 ・longは「intと等しいか、或いは大きい」 ってあたりを考えると間違いではないのですが…。 未だにこの話を時々思い出します ^^;
たしかgccのどっかだかのバージョンでテスト的にlong long intが 実装されてたような…。 この辺あまり記憶が定かではないのですが。 以上余談でした〜。 | ||||||||
|
投稿日時: 2004-03-08 15:29
ちなみにこの場合のバイトとは9ビット? sizeof(int)は4、sizeof(char)は1ですよね? ということはintは36ビットとか? さらに余談でした〜 #もはやCはかなり忘れているので、とんでもないこと書いてるかも… |