アカウント名:
パスワード:
結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー
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)
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね?
まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
これはちょっと違うのでは?
仕様として決まっている事は全部テストでチェックすればいいだけだし。
仕様定義やテストの漏れこそが致命的であって、その部分のチェック
の方が重要だと思う。
ソース
--- (´-`)。oO(平和な日常は私を鈍くする) ---
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
(量産型の家と特注の家。どちらに住みたいかは人それぞれですが。)
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
小規模プロジェクトの場合、設計担当者が製造の現場監督を兼任することもある、
という実例ですね。
設計担当者には製造の現場監督とし
Re:time_tをsigned __int64に変更するとしたら (スコア:0)