time_t と 2038年問題

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チェックの必要性を考える