2017年12月10日

改めて2038年問題を考える…すでに2004年に問題が発生していたとは知らなかった

昨日、TL上で2038年問題に関する話題が上がっていて、そういえば、2038年問題って、実際に発生するXデーがいつなのかよく分かっていなかったことに気づきました。

2000年問題なら、2000/1/1 0:00:00 という、一般人でも分かりやすい日付時刻に発生する事象でしたが、2038年問題はそんなに分かりやすい日付時刻ではないはず。C言語を扱うプログラマ以外の一般の人にとっても、わかりにくい事象となるでしょう。

2038年問題とは、C/C++のtime_t型が1970年1月1日0時0分0秒からの積算秒数と定義されており、その最大値の一般的な実装が2,147,483,648となっていることから、その最大値を超えたときに不具合が発生するというものです。

というわけで、Xデーは、世界協定時で2038年1月19日03時14分7秒(UTC)となります。
日本時間だと、2038年1月19日12時14分7秒(JST)になるので、もしトラブルが発生するとしたら真っ昼間です。大混乱になるかもしれません。

2000年問題の時と同様に、全世界のSEが血眼になって、問題が発生しないよう努力するはずなので、きっと何も起きないはず…であることを祈りたいです。

この問題をWikipediaで調べていて知ったのですが、2004年には既に、2038年問題を原因とするトラブルが発生していたんだそうでビックリです。


続きを読む
posted by ayacy at 00:24 | Comment(0) | TrackBack(0) | C/C++

2016年01月20日

Visual C++ 2010のfwriteの限界?

先日、お仕事で、後輩の作っているプログラムを見る機会があったのですが、そこで、ちょっと不思議な挙動を見たのでメモ。

Visual C++ 2010で、fwrite() 関数に対して500MB近いバッファを与えて、一気に書き込みをしようとしていたのですが、fwrite() 関数が戻り値0でエラーリターンしていました。errnoを調べると、「Invalid argument」(不正な引数)を示していました。

試しに、次のどちらかを試すと、問題は解消しました。

  • fwrite()に与えるバッファサイズ・書き込みサイズを200MB近くまで下げる。
  • fopen()するときに、modeとして "wb" ではなく "wb+" を与える。

おそらく、Visual C++ 2010 の fwrite() 関数の実装か、その実装で使われている Windows API (WriteFile() APIか何か?) の制限があるのでしょう。一度に書き込める限界があったのかも知れません。

fopen() するときのmodeに"+"を付けると問題が解決する理由もよく分かりませんが、"+"は読み書き兼用のファイルを開くことを意味しており、読み書きのために多くのバッファを確保できる仕組みがあるのかも知れません。

ネット上で検索しても、それっぽい情報が出てこなかったので、ちょっと不思議に思いまして。

あるいは、ハードウェア的に、いわゆる DMA 的なやつが連続して扱えるメモリ量に限界があるとか?そういったものもあるんでしょうか。そこら辺はよく分からないですけどね。

posted by ayacy at 00:00 | Comment(0) | TrackBack(0) | C/C++