パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

2038年問題、早くも顕在化」記事へのコメント

  • 世界全体で合計どのくらいコストがかかるのかな。

    #ILP64な環境だとtime_tはどう定義されてるか興味津々
    • by Anonymous Coward on 2004年02月03日 13時16分 (#487140)
      > time_tをsigned __int64に変更するとしたら

      time_tそのものは32bitだと決まってるわけではないので
      変更の必要性はありません。

      ちゃんと作ってればソースへの変更は不要。
      もっとちゃんと作ってればリコンパイルも不要。
      数十年や数百年先、
      さらには同じような扱いで数十年前や数百年前の時刻を
      秒単位で管理するソフト作る場合は
      始めからtime_tを利用せず代替ライブラリーを自分で用意するし。

      結局のところ表現したい時刻の範囲と
      それぞれの型によって表現可能な時刻の範囲の問題に関して
      ちゃんと考えたことがあるのか、それともないのか
      という点につきますよ

      どういう理由でそんな仕様にしたのか尋ねても「覚えてない」
      「何も考えてなかった」とか言い出す連中は
      設計の段階で何も検証してません。
      「最後のテストがちゃんと通ったんだからそれでいいじゃん」というような
      テスト至上主義がつくったソフトは
      環境の変化や想定外の状況に遭遇したとき
      「そうなって当り前だろ?」と笑われるようなものを平気で作ります。

      そういうおかしな物作りをするような職人のプライドもヘッタクレも
      無いようなところを無くすことができない以上、
      そんなところに発注するクライアントの責任が一番重大。
      クライアントは発注先とは独立してコンサル雇って
      設計段階で発注先の物の考え方を探っておきなさいってこった。
      今のIT業なんて外からみたらみんな同じに見えても
      中を開けるとプロ野球と少年野球くらいの違いがあるんだから
      その違いを無視して安いところを探してたらダメ。
      親コメント
      • 結局のところ表現したい時刻の範囲と それぞれの型によって表現可能な時刻の範囲の問題に関して ちゃんと考えたことがあるのか、それともないのか という点につきますよ

        ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を行わないという選択肢もありますよね?
        まだ、そういう仕様のところって多いんじゃないかなぁ。

        と、それはそれとして…

        どういう理由でそんな仕様にしたのか尋ねても「覚えてない」

        • by hix (3507) on 2004年02月03日 15時30分 (#487244) 日記
          2038/01/19 03:14:07 UTCを過ぎたら、それ以前のことは全て忘れてしまえばよいのです。

          以降、time_tの説明には
          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型に正の秒数で格納されます。当面の時刻を正常に表す事ができます。
          とでも書いておけば宜しい。
          親コメント
        • >結局はソースレビューするしか品質を維持できないと思ってます。

          これはちょっと違うのでは?
          仕様として決まっている事は全部テストでチェックすればいいだけだし。
          仕様定義やテストの漏れこそが致命的であって、その部分のチェック
          の方が重要だと思う。
          ソースレベルのチェックなんてコーディング規約ぐらいのもんだろうから
          その辺はプログラマレベルで解決して欲しい。
          間違っても上位設計者にそんなことやらせちゃ駄目です。
          建築士が柱を運ぶようなもんで、職掌(や単価)が違うんだから。
          --

          --- (´-`)。oO(平和な日常は私を鈍くする) ---
          親コメント
        • ちゃんと考えて、製品のソフトウェアサイクルから2038年以内限定とし、特に対処を 行わないという選択肢もありますよね? まだ、そういう仕様のところって多いんじゃないかなぁ。

          「多い」と結論付ける資料も計算式も不明ですが。

          結局はソースレビューするしか品質を維持できないと思ってます。

          実装ではなくその前段階の設計に関する問題です。 実装されたあとのソースに対して検証しても手遅れだし、 問題を指摘して設計からやり直せという指摘が正しいものだとしても それはコストがかかりすぎるということで 設計をそ

          • ソースの品質を向上させたり保証する能力と設計に関する能力を一緒にしちゃダメってことです。

            まぁ、普通そういう人が多いことは知っていますが(そうじゃないと困る人が多いというか)、今の現状でいうと、ソースも読めない人が上位設計をやっていることが結構あるんですね。で、本人は上級なことをやっている気になっているんですが、元々ソースも読めない

      • そうそう、x86_64のlinuxでは、time_tを64bitで扱っている。 turbolinux 64、suse 9.0 64など。
      • by Anonymous Coward
        > クライアントは発注先とは独立してコンサル雇って
        > 設計段階で発注先の物の考え方を探っておきなさいってこった。
        > 今のIT業なんて外からみたらみんな同じに見えても
        > 中を開けるとプロ野球と少年野球くらいの違いがあるんだから
        > その違いを無視して安いところを探してたらダメ。

        理想はそうでしょうが、現実問題これを出来る予算規模の仕事と
        「それがわかるコンサル」の両方が揃って初めて可能
      • >もっとちゃんと作ってればリコンパイルも不要。

        どのようにちゃんと作ったらこれまでスタックに4Byte積んでたものが勝手に8Byte積むようになったり、time_tのデータを含む構造体のサイズが勝手に4×nByte増えたり、sizeof(time_t)でコンパイル時に4になってた値が勝手に8になったりするの?

        >環境の変化や想定外の状況に遭遇したとき
        >「そうなって当り前だろ?」と笑われるようなものを平気で作ります。

        テスト至上主義者じゃなければ想定外の状況に遭遇した時「そうなって当たり前だろ?」と笑われるものにならないの?
        想定外の状況なのにどうやって対策してたの?
        単に

        • 元コメント者じゃないけど、
          もっとちゃんと=time_tを使わずに独自の時間型or構造体を使っている
          ということだと思われる。
          • 独自の型を作って独自の処理をして独自のバグを発生させたりしたら「ライブラリ知らないバカ」と言われるというオチをご期待ですか?

            という話は置いといて、脊髄反射するんじゃなくてもっとちゃんと文脈を読みましょう。
            >time_tをsigned __int64に変更するとしたら
            どうなるかという話の中で
            >ちゃんと作っ

            • > 独自の型を作って独自の処理をして独自のバグを発生させたりしたら
              > 「ライブラリ知らないバカ」と言われるというオチをご期待ですか?

              数十年数百年の範囲を秒単位で表現したいという要求を前にしたとき
              「time_tのライブラリー利用」を選べば問題発生が明らかである場合、
              そのことを理解した上でライブラリーを選ばない判断をしたことに対して
              「ライブラリ知らないバカ」
              というのは適用できない。

              そもそも「独自のバグを発生させたりしたら」
              を前提にしてたら何も作れないね。
              このストーリーで触れられているバグなんて
              独自で作成した型ではなくライブラリーの型を利用してい
              • だからさ、話の流れをちゃんと読めよ。
                #487101でsugarfreeさんは「time_tをsigned __int64に変更するとしたら世界全体で合計どのくらいコストがかかるのかな。」という疑問を呈している訳でしょ?
                それに対して「time_t使
              • > だからさ、話の流れをちゃんと読めよ。

                誰が読めていないのかは一目瞭然。

                > #487101でsugarfreeさんは「time_tをsigned __int64に変更するとしたら世界全体で合計どの
                > くらいコストがかかるのかな。」という疑問を呈している訳でしょ?
                > それに対して「time_t使ってなければ関係無い」って何の回答にもなってないじゃん。

                それへの回答は
                「time_tそのものは32bitだと決まってるわけではないので変更の必要性はありません。」
                で終ってるでしょう。
                それ以降の「ちなみに変更といえば」といわんばかりの雑談部分や
                それに対するコメント全てが回答であるわけじゃないし。

                time
            • >「time_tを使わなければtime_tが変わっても問題無い」というのは
              >何も大威張りで言わなくても当たり前な事で何の解決にもなってない

              で、その当たり前のことができていないという話でしょ。
              もっとちゃんと考えて作ってれば、関係

アレゲはアレゲ以上のなにものでもなさげ -- アレゲ研究家

処理中...