アタマに浮かんだ。もうかなり前になるが西暦2000年問題というのがあったけどあの騒ぎは一体なんだったのだろう。でも次に来る2038年問題は結構深刻らしい。オレもそー思う。2038年問題でググっていただければお分かりかと思うが、2038年問題とはC言語で書かれたUNIXシステムにおける時刻の取り扱い仕様に起因する問題です。簡単に言えば2038年で時刻を扱うレジスタがオーバーフローを起こしてしまうのです。今ネットワーク上でサーバーとして活躍しているマシンはその多くがUNIX系OSであることを考えると結構アタマの痛い問題と思われます。今から20年くらい前、UNIXシステム上でCプログラミングを始めたばかりのころのオレはシステム時刻を表す"time_t"が"unsigned long"ではなく"long"にtypedefされていることを見て、いやーこれは案外早くオーバフローするんでねーの？と思って計算してみた。"long"ちゅーこんは最上位ビットが符号で喰われるから32ビットではなく31ビットしか有効でねーんじゃん。２の31乗から１引くと「2147483647(=0x7FFFFFFF)」で、1970年1月1日0時0分0秒から１つづつカウントアップしていけばどーなるんじゃろ。
2147483647÷60÷60÷24÷365≒68年だろ。
ちゅーこんは、1970年+68年=2038年でオーバーフローかぁ？
てな具合。
その時は1980年代だもんで2000年問題さえ気にしてなかった。UNIXやC言語の仕様考えた人だってそんなに遠い未来のこと考えてたわけじゃないんだろーなぁ。TCP/IPで使われるIP(v4)アドレスが32ビットなためアドレス空間が枯渇しそーな状況とおなじで、初めは実験・研究の類からボランティアの人たちによって成長してきたシステムなんでしょう。ここまで使われるとは想定していなかったんだよなぁ。せめて"time_t"が"unsigned long"でtypedefされていれば32ビット分使えるからもうちょっと先延ばしできたのに、なんで"long"でtypedefしたのかなぁ。この辺知っている人いたら教えてくらはい。
コメントする