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

誰も Linux kernel ソースを読んでいない？ More

「誰も Linux kernel ソースを読んでいない？」記事へのコメント

  • 確かに誰も読んでいないようだな (スコア:2, すばらしい洞察)

    by Anonymous Coward on 2006年04月08日 22時12分 (#917704)
    たしかに今のコードは誰も読んでいないようだな。

    /*
      * Convert an ICMP "type" field to a printable string.
      */
    char *
    pr_type(register u_char t)
    {
            static char *ttab[] = {
            "Echo Reply", "ICMP 1", "ICMP 2", "Dest Unreachable",
            "Source Quench", "Redirect", "ICMP 6", "ICMP 7",
            "Echo", "ICMP 9", "ICMP 10", "Time Exceeded",
            "Param Problem", "Timestamp", "Timestamp Reply", "Info Request",
            "Info Reply"
            };

            if (t > 16)
                    return("OUT-OF-RANGE");

            return(ttab[t]);
    }

    • Re:確かに誰も読んでいないようだな (スコア:1, 参考になる)

      by Anonymous Coward on 2006年04月09日 1時07分 (#917772)
      ははあ、なるほど。Debian/sargeのtraceroute には
      -       if (t > 16)
      +       if (t > 18)
      のパッチが当たってました(traceroute_1.4a12-18.diff.gz)。
      シェア
      親コメント
      • sizeof ttab / sizeof(char*) を使うところだと思うんだけど、なぜ即値なのだー。

        • >なぜ即値なのだー。

          あくまで一般的な例では
          1.その手の定型文を使い慣れていなかった。
          2.単に面倒だった。(or 時間が無かった)
          3.コンパイラによっては割り算が入るので遅くなる。
          　(最適化がコンパイラ任せというのは好まない)
          4.仕様が定まっていなかったので有効なのは途中までだった。
          あたりかと。
          • は？

            >3.コンパイラによっては割り算が入るので遅くなる。
            > (最適化がコンパイラ任せというのは好まない)
            実行時の演算結果に影響しない定数式はコンパイル時に計算されますよ。
            こういう人はC++がものすごく遅い言語だと思っているんでしょうね。Kernel Sourceを読む前にCompiler Sourceを読んだ方がいいかもｗ
            • 「コンパイラによっては」って書いてあるのに読めませんかね?
              • >「コンパイラによっては」って書いてあるのに読めませんかね?

                何十年前のコンパイラですか・・・

                いまどき、このコードで実行時の除算が生成されるなんて、びっくりです。
                件のソースがコンパイル可能で、かつそのようなコードを生成する処理系をご存知ならば、参考までにお教え願いたい。
              • お手軽処理系だとありそうだけどね。
                たとえばyaccでほげってでっちあげた処理系とか。

                本筋に戻ると
                sizeof ttab / sizeof(char*)
                とするとバイト境界をそろえるためにパディングを入れたときに困るでしょ。
              • pcc ってそんなもんだったような記憶があるけど、どうだったかな?
              • >とするとバイト境界をそろえるためにパディングを入れたときに困るでしょ。

                えーなんか困りますか? 解説キボン
              • バイト境界をそろえるためにパディングを入れたときに困るでしょ。(このケースでは全く全然関係ない:-1)
              • えーこのケースでは全く全然関係ないなら全く全然困らないんでは? 解説キボン
              • たとえばこういう処理系な。
                ポインタが24bit長で、16bit単位でアクセスを行うRAMが繋がっているために配列に1バイトパディングする。
                メモリの利用効率は悪化するけどな。
                sizeof(char *) = 3
                sizeof(ttab) = 4の倍数
              • ポインタが24bit長でメモリアクセスが16bit単位なら偶数アドレスに配置されようが奇数アドレスに配置されようが2度アクセスすることに変わりはないしパディングは意味ないのでは?
              • > 偶数アドレスに配置されようが奇数アドレスに配置されようが

                奇数番地からのアクセスを許さないCPUはありますね（本当）。例のプログラムは、そこまで考え抜かれて作られたものだったわけです（嘘）。

              • 偶数境界への整列が強制されるのならば、sizeof(char*)は3でなく4になるのではないのですかねえ。
                きりがないので、「sizeof ttab / sizeof(char*)」や「sizeof ttab / sizeof ttab[0]」が誤った結果を返す、
                具体的なアーキテクチャ名を例示いただけるとありがたいです。
            • 読むべきなのは、コンパイラのソースではなくて言語の仕様書だと思うのだが。
              • # 私の指摘は冗長なものでしたか…その割には議論が進んでるんですが。
                # 不当マイナスモデ希望ｗ

                >言語の仕様書
                K&R 2ndを調べました。
                A constant expression is an expression that involves only constants. Such expressions may be evaluated during compilation rather than run-time, and accordingly may be used in any place that a constant can occur,
                とあり、mayなので仕様的には決まってないです。やっぱりコンパイラのソースを読むしか。
                ちなみにLSI-C 3.30c試食版で動作を確認してみたら、定数式はコンパイル時に計算されていました。

                ポインタのパディングは実際どうなんでしょ。
                malloc( sizeof(char*) * n )
                もできないわけで、そんな怖い処理系が実在するんでしょうか？
                シェア
                親コメント
      • それは

        - "Info Reply"
        + "Info Reply", "Mask Request", "Mask Repl

        と合わせてのパッチだから本質的に意味のない話だよ。
    • たしかに今のコードは誰も読んでいないようだな。
      どういう意味ですか? 何か間違いが見過ごされているという意味なら気になります。

      引用されているのは IPv4 用の traceroute のコードの一部ですよね。少なくとも FreeBSD [freebsd.org] ではこの通りのコードが使われているようです。
      --
      鵜呑みにしてみる？
      シェア
      親コメント
      • 単にInfo Reply がコード上は機能しない　と言う事でしょう。
        アドレスが０始まりなので、Info Replyは16番目だが、
        引数で 16 を渡してもOUTRANGEになる。

        ただ、RFC的にはInfomation Reply は廃止されているので、call元が使っていないならば、Info Replyを
        必要としていないので、問題が表面化しない　と言う事かと。
        ＃でも 17番目と18番目が RFC792では無く、RFC 950で提唱
        ＃されいるのが対応していないようですが。

にわかな奴ほど語りたがる -- あるハッカー