今度は3000年問題/でも「2038年問題」を忘れるな – ニュースの雑感

http://headlines.yahoo.co.jp/hl?a=20070214-00000036-zdn_ep-sci(PC専用)

今度はVisual C++を使用したプログラム(正確にはライブラリ)に「西暦3000年問題」が起こる可能性があるのだという。

一時期2000年問題が騒がれたことはまだ記憶にあたらしいと思うが、次は3000年。まぁ、そこまで人類の文明が残っているかどうか、という問題はさておき、やはり3000年後のことなど考えていられないというのが正直なところなのだろうか。

ちなみに、これは何も「1000年後」に影響が出る「遠い未来」の話ではない。現在でも悪意のある誰かが西暦3000年以降というおかしなデータを入力するとプログラムが強制終了してしまうこともあるらしい。原理はY2Kとそれほど変わらないと思う。

ただ、これはDLLを入れ替えるだけで大丈夫じゃないかな。
少なくともセキュリティ的には。

でも、もっと身近な問題がある。
「2038年問題」だ。

現行のシステムではUNIX時間(ユニックス時間)という時間の表現方法を使っていることが多いと思う。(UNIXシステム以外でも)

この時間の表し方は1970年1月1日午前0時からの秒数で現在の時間を表している。だが、32ビット処理系では、扱える正の数値の限界が最大で「21億4748万3647」となっている。(signed long int型の場合)

したがって、UNIX時間の原点から21億4748万3647秒後の2038年1月19日日本時間12時14分07秒、UNIX時間を使用する32ビットシステムは桁あふれを起こし、最悪の場合システムがダウンすることも考えられる。

実際、既に2004年の段階でこの2038年問題が原因で銀行ATMが誤作動したという事件もあった。

この問題は、現在、世界でもっとも標準的に採用されているシステムの仕様に起因する問題なので、もしかすると2000年問題よりも深刻かもしれない。
DLLを入れ替えるだけではなくて、もう一度プログラムをコンパイルしなおさないといけないので。

もっとも簡単な対策は64ビットの整数型に切り替えてコンパイルしなおすことだが、2000年問題のように古いシステムがいまだに使われていることもあり、それと同様に2038年にも32ビット整数型を使用して動いているシステムが存在することは想像に難くない。

でも、この問題、「システムをごっそり64ビットのCPUで動かせば解決じゃん」と勘違いしていると痛い目にあいそうだ。64ビットのCPUで動かしていても32ビットのプログラムは32ビットなので。

ってそんなやつおるかい

しかし、UNIX時間を考えた人は2038年のことは考えなかったのかなぁ。
僕自身も先のことはあまり考えないでプログラムを組んでいるので、気をつけないといけないな…… 

※32ビットシステムとは32ビット整数型を使っているプログラムの意味で書いた。32ビットCPU上のプログラムでも64ビット整数型は使用できるため、この問題は回避できる。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です