アカウント名:
パスワード:
どのようにちゃんと作ったらこれまでスタックに4Byte積んでたものが勝手に8Byte積むようになったり、time_tのデータを含む構造体のサイズが勝手に4×nByte増えたり、sizeof(time_t)でコンパイル時に4になってた値が勝手に8になったりするの?
>環境の変化や想定外の状況に遭遇したとき >「そうなって当り前だろ?」と笑われるようなものを平気で作ります。
テスト至上主義者じゃなければ想定外の状況に遭遇した時「そうなって当たり前だろ?」と笑われるものにならないの? 想定外の状況なのにどうやって対策してたの? 単に
という話は置いといて、脊髄反射するんじゃなくてもっとちゃんと文脈を読みましょう。 >time_tをsigned __int64に変更するとしたら どうなるかという話の中で >ちゃんと作っ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
time_tをsigned __int64に変更するとしたら (スコア:1)
#ILP64な環境だとtime_tはどう定義されてるか興味津々
Re:time_tをsigned __int64に変更するとしたら (スコア:2, すばらしい洞察)
time_tそのものは32bitだと決まってるわけではないので
変更の必要性はありません。
ちゃんと作ってればソースへの変更は不要。
もっとちゃんと作ってればリコンパイルも不要。
数十年や数百年先、
さらには同じような扱いで数十年前や数百年前の時刻を
秒単位で管理するソフト作る場合は
始めからtime_tを利用せず代替ライブラリーを自分で用意するし。
結局のところ表現したい時刻の範囲と
それぞれの型によって表現可能な時刻の範囲の問題に関して
ちゃんと考えたことがあるのか、それともないのか
という点につきますよ
どういう理由で
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
どのようにちゃんと作ったらこれまでスタックに4Byte積んでたものが勝手に8Byte積むようになったり、time_tのデータを含む構造体のサイズが勝手に4×nByte増えたり、sizeof(time_t)でコンパイル時に4になってた値が勝手に8になったりするの?
>環境の変化や想定外の状況に遭遇したとき
>「そうなって当り前だろ?」と笑われるようなものを平気で作ります。
テスト至上主義者じゃなければ想定外の状況に遭遇した時「そうなって当たり前だろ?」と笑われるものにならないの?
想定外の状況なのにどうやって対策してたの?
単に
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
もっとちゃんと=time_tを使わずに独自の時間型or構造体を使っている
ということだと思われる。
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
という話は置いといて、脊髄反射するんじゃなくてもっとちゃんと文脈を読みましょう。
>time_tをsigned __int64に変更するとしたら
どうなるかという話の中で
>ちゃんと作っ
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
> 「ライブラリ知らないバカ」と言われるというオチをご期待ですか?
数十年数百年の範囲を秒単位で表現したいという要求を前にしたとき
「time_tのライブラリー利用」を選べば問題発生が明らかである場合、
そのことを理解した上でライブラリーを選ばない判断をしたことに対して
「ライブラリ知らないバカ」
というのは適用できない。
そもそも「独自のバグを発生させたりしたら」
を前提にしてたら何も作れないね。
このストーリーで触れられているバグなんて
独自で作成した型ではなくライブラリーの型を利用していながら
結局バグを発生させているのだから、
「バグを発生させたりしたら」なんてものは独自であろうがなかろうが
発生するものは発生する。
「独自のバグを発生させたりしたら」のように及び腰で問題に立ち向かう
開発集団というのは、そもそも時刻処理に関して自信がないわけで、
どのような選択をしてもバグから逃れないだろうし。
> 「time_tを使わなければtime_tが変わっても問題無い」
> というのは何も大威張りで言わなくても当たり前な事で何の解決にもなってない。
2038年問題などtime_tに纏わる問題に対しては解決になる。
何も無理をして絶対にtime_tを使用しなければならない理由なんてない。
未来側のオーバーフローは32bitを64bitに変えれば良いかもしれないが、
それでは過去側に関しての解決になっていない。
time_tなんてものは時刻処理に関する便宜上の簡単なサンプルに過ぎないし
POSIX的には閏秒の存在を無視するという玩具のような存在。
真面目に時刻処理をしなければならない状況なら始めからtime_tは論外。
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
#487101でsugarfreeさんは「time_tをsigned __int64に変更するとしたら世界全体で合計どのくらいコストがかかるのかな。」という疑問を呈している訳でしょ?
それに対して「time_t使
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
誰が読めていないのかは一目瞭然。
> #487101でsugarfreeさんは「time_tをsigned __int64に変更するとしたら世界全体で合計どの
> くらいコストがかかるのかな。」という疑問を呈している訳でしょ?
> それに対して「time_t使ってなければ関係無い」って何の回答にもなってないじゃん。
それへの回答は
「time_tそのものは32bitだと決まってるわけではないので変更の必要性はありません。」
で終ってるでしょう。
それ以降の「ちなみに変更といえば」といわんばかりの雑談部分や
それに対するコメント全てが回答であるわけじゃないし。
time