10周年のSPコンテンツ!
13
Shinji Kono @shinji_kono
OS が64bit なのと time_t の問題は独立だから、2038年問題とは直接は関係しない。sizeof(time_t) =4 なOSを見つけるのは、もはや難しいんじゃないかなぁ。
Izumi Tsutsui @tsutsuii
time_t はたいていの実装で long だったので LP64なCPUだったら最初から time_t は64ビットだったという話のような
Izumi Tsutsui @tsutsuii
LP64はCPUじゃなくて実装の選択か。WindowsはLLP64って書いてあるから 64ビットCPUでもlong 32ビットで、 time_t は long long なのか? という話か
Izumi Tsutsui @tsutsuii
OS側で time_tを64ビットにしたところでRTCのようなハードウェアやUFS1みたいなon diskフォーマットには 32ビット time_t 表現が残ってて、それらは交換しない限りどうしようもないからとりあえずunsignedにするか適当な判定入れるか何かしら対処が必要
Takeshi HASEGAWA @hasegaw
みんな2038年までに引退すべく頑張ってるよね RT @tsutsuii: そういう太古のハードが生き残るシステムは わざわざ更新するメリットがない もしくは もはやメンテ不能 ということだから、結局2038年にはいろんなことが起こるだろうという予想
Kazuo Moriwaka @moriwaka
@shinji_kono 今の問題はtime_tそのものから、time_tに由来して作られた各種データになってますね。dumpのファイルフォーマットとか、ext3のタイムスタンプとか、32bit整数として定義されちゃったものが……
Izumi Tsutsui @tsutsuii
time_t を 64ビットにしたところで、time_t の差分を求める計算の実装で一時変数を int にしちゃってたとか 明示的に2038年チェックが残ってたとかで結局 2038年になったら動かなくなった、なんて事例はNetBSDですでに実証済み
Izumi Tsutsui @tsutsuii
http://t.co/gNEU3N2BmN time_t 計算を long で行っていた事例 http://t.co/aOdAcNtgG3 2038年チェックが残っていた事例 http://t.co/CB2WgPpjHf ハード側が4バイトしかないのに8バイト読んでた事例
Izumi Tsutsui @tsutsuii
@hasegaw 古いハードはともかく古いソフトはなにかしら残るでしょうから 32bit time_t checker とか作ると商売になるんですかね〜
Izumi Tsutsui @tsutsuii
EEPROMから time_t 読み出し →ハード側が4バイトしかないのに8バイト読んでしまう →年の値が巨大になる →年の桁が多すぎると ctime(3) が NULLを返す →そのまま表示しようとしてぬるぽ という斜め上事例を目の当たりにしてNULLチェックの必要性を考える
ログインして広告を非表示にする
ログインして広告を非表示にする