アカウント名:
パスワード:
OSの内部的な時刻の表現は64ビット化が進んでいて西暦3000億年まで大丈夫になりつつあるようです。スクリプト系言語は32ビットとして扱ってなければそのままでも大丈夫なような。データベースのカラムが32ビットだったらダメですけど。time型カラムとかdatetime型カラムは対応が進んでそう。
それにしても動作確認が大変そうですね・・・
実際のところ, 抽象的な時刻型で記述してあるプログラムについては, それほど大きな問題にはならないのではないかと思います.
問題なのは時刻型を32bit符号付き整数という前提でcastして取り扱っていたり, あるいはcastさえせずにwarning無視で使っていたりするケースじゃないでしょうか. そういう類のプログラムだと, 事は時刻型だけにとどまらず他の各種のデータについても同様の潜在バグを抱えていることがままあります. そうすると, 今日的なチェックの厳しいコンパイラだとコンパイルを通らない. コンパイルを通っても, そもそもバグを抱えていたのがたまたま動いていただけなので, まともに動きようがない. 結果としてプログラムの直しようもなく, 旧来のバイナリをそのまま使わざるをえない. ってところかと.
Cなんかが業務システムで使われるようになって, そろそろ30年ってところですから, ソースが紛失したなんてケースも少なからずありそうな.
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」
意外と大丈夫? (スコア:0)
OSの内部的な時刻の表現は64ビット化が進んでいて西暦3000億年まで大丈夫になりつつあるようです。
スクリプト系言語は32ビットとして扱ってなければそのままでも大丈夫なような。
データベースのカラムが32ビットだったらダメですけど。time型カラムとかdatetime型カラムは対応が進んでそう。
それにしても動作確認が大変そうですね・・・
Re:意外と大丈夫? (スコア:2)
実際のところ, 抽象的な時刻型で記述してあるプログラムについては, それほど大きな問題にはならないのではないかと思います.
問題なのは時刻型を32bit符号付き整数という前提でcastして取り扱っていたり, あるいはcastさえせずにwarning無視で使っていたりするケースじゃないでしょうか. そういう類のプログラムだと, 事は時刻型だけにとどまらず他の各種のデータについても同様の潜在バグを抱えていることがままあります. そうすると, 今日的なチェックの厳しいコンパイラだとコンパイルを通らない. コンパイルを通っても, そもそもバグを抱えていたのがたまたま動いていただけなので, まともに動きようがない. 結果としてプログラムの直しようもなく, 旧来のバイナリをそのまま使わざるをえない. ってところかと.
Cなんかが業務システムで使われるようになって, そろそろ30年ってところですから, ソースが紛失したなんてケースも少なからずありそうな.