アカウント名:
パスワード:
結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
time_t型に格納される数値は 2106/02/05 21:28:16 UTCまでの秒数を負の値で表したものです。 time_t型が正常に動作する最も古い時刻は2038/01/19 03:14:08 UTC です。 それより前の時刻をコンピュータで取り扱うのは原因不明の事故や故障に繋がりますのでおやめください。非常に危険です。多分死人が出ます。 2038/01/19 03:14:08 UTC より前からの債権について金利計算を行うには、正常に動作する時刻からの金利とすることが最善の解決策です。 なお、2106/02/05 21:28:16 UTCを過ぎた時刻は、time_t型に正の秒数で格納されます。当面の時刻を正常に表す事ができます。
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を 行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。
「多い」と結論付ける資料も計算式も不明ですが。
結局はソースレビューするしか品質を維持できないと思ってます。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ
ソースの品質を向上させたり保証する能力と設計に関する能力を一緒にしちゃダメってことです。
まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない
glibc 2.3.2 には long int と書いてありました。
# generic に書いてあるのに誰も override してないっぽい
どのようにちゃんと作ったらこれまでスタックに4Byte積んでたものが勝手に8Byte積むようになったり、time_tのデータを含む構造体のサイズが勝手に4×nByte増えたり、sizeof(time_t)でコンパイル時に4になってた値が勝手に8になったりするの?
>環境の変化や想定外の状況に遭遇したとき >「そうなって当り前だろ?」と笑われるようなものを平気で作ります。
テスト至上主義者じゃなければ想定外の状況に遭遇した時「そうなって当たり前だろ?」と笑われるものにならないの? 想定外の状況なのにどうやって対策してたの? 単に
という話は置いといて、脊髄反射するんじゃなくてもっとちゃんと文脈を読みましょう。 >time_tをsigned __int64に変更するとしたら どうなるかという話の中で >ちゃんと作っ
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
目玉の数さえ十分あれば、どんなバグも深刻ではない -- Eric Raymond
time_tをsigned __int64に変更するとしたら (スコア:1)
#ILP64な環境だとtime_tはどう定義されてるか興味津々
Re:time_tをsigned __int64に変更するとしたら (スコア:2, すばらしい洞察)
time_tそのものは32bitだと決まってるわけではないので
変更の必要性はありません。
ちゃんと作ってればソースへの変更は不要。
もっとちゃんと作ってればリコンパイルも不要。
数十年や数百年先、
さらには同じような扱いで数十年前や数百年前の時刻を
秒単位で管理するソフト作る場合は
始めからtime_tを利用せず代替ライブラリーを自分で用意するし。
結局のところ表現したい時刻の範囲と
それぞれの型によって表現可能な時刻の範囲の問題に関して
ちゃんと考えたことがあるのか、それともないのか
という点につきますよ
どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
「何も考えてなかった」とか言い出す連中は
設計の段階で何も検証してません。
「最後のテストがちゃんと通ったんだからそれでいいじゃん」というような
テスト至上主義がつくったソフトは
環境の変化や想定外の状況に遭遇したとき
「そうなって当り前だろ?」と笑われるようなものを平気で作ります。
そういうおかしな物作りをするような職人のプライドもヘッタクレも
無いようなところを無くすことができない以上、
そんなところに発注するクライアントの責任が一番重大。
クライアントは発注先とは独立してコンサル雇って
設計段階で発注先の物の考え方を探っておきなさいってこった。
今のIT業なんて外からみたらみんな同じに見えても
中を開けるとプロ野球と少年野球くらいの違いがあるんだから
その違いを無視して安いところを探してたらダメ。
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね?
まだ、そういう仕様のところって多いんじゃないかなぁ。
と、それはそれとして…
行員矢の如し (スコア:1)
以降、time_tの説明には とでも書いておけば宜しい。
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)
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
「多い」と結論付ける資料も計算式も不明ですが。
実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
Re:time_tをsigned __int64に変更するとしたら (スコア:1)
glibc 2.3.2 には long int と書いてありました。
# generic に書いてあるのに誰も override してないっぽい
言うは易し (スコア:0)
> 設計段階で発注先の物の考え方を探っておきなさいってこった。
> 今のIT業なんて外からみたらみんな同じに見えても
> 中を開けるとプロ野球と少年野球くらいの違いがあるんだから
> その違いを無視して安いところを探してたらダメ。
理想はそうでしょうが、現実問題これを出来る予算規模の仕事と
「それがわかるコンサル」の両方が揃って初めて可能
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のライブラリー利用」を選べば問題発生が明らかである場合、
そのことを理解した上でライブラリーを選ばない判断をしたことに対して
「ライブラリ知らないバカ」
というのは適用できない。
そもそも「独自のバグを発生させたりしたら」
を前提にしてたら何も作れないね。
このストーリーで触れられているバグなんて
独自で作成した型ではなくライブラリーの型を利用してい
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
Re:time_tをsigned __int64に変更するとしたら (スコア:0)
>何も大威張りで言わなくても当たり前な事で何の解決にもなってない
で、その当たり前のことができていないという話でしょ。
もっとちゃんと考えて作ってれば、関係