アカウント名:
パスワード:
さて,liloが正しくコンパイルできない原因は何なのでしょうか?
# grub も lilo もダメになるんだったら 3.4.x 系列への移行やめるかな... # まあ試せばすぐ分かることですが。
実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができるということでしょう。
実行時環境とは何の関係もありませーん。スタティックリンクを含めたアクティベーションレコードやディスプレイをセットアップするのはコンパイラのお仕事です(スタティックリンクを含めてアクティベーションレコードをきちんとセットするようなコードを生成する訳ですから)。つまり、Cはコン
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
開いた括弧は必ず閉じる -- あるプログラマー
ソースコードの書き方にも問題がある. (スコア:4, 興味深い)
grubがコンパイラのバグという地雷を踏んだ理由の一つとして
そのソースコードの書き方にも原因があると思います.
grubの該当するソースコードは,関数の中で関数を定義するという妙な記述をしています.
これは,一般的なC言語の文法上はエラーになるので,めったに利用されない書き方です.gcc以外ではコンパイルさえ出来ない気がします.
このような普段あまり利用されない記述をしているから,
コンパイラのバグに引っかかるという見方も出来ると思います.
さて,liloが正しくコンパイルできない原因は何なのでしょうか?
気になるところです.
Re:ソースコードの書き方にも問題がある. (スコア:3, 興味深い)
それはそれで問題あると思うのですが、IA32プラットフォームでそういうのをコンパイルしたとき、スタック上に実行コードを乗っけて、そこに分岐する、という野蛮な実装は他の CPU ではどういうコードに落ちるんでしょう。
(私の思い違いでなければ)IA64では、他のまっとうな高機能 CPU と同様にテキストセグメントとデータセグメントが明確に分かれていてスタック上の番地にジャンプするなんてことはできないと思うのですが。
もしかして gcc の IA32 への対応のしかたが悪いだけ?
Re:ソースコードの書き方にも問題がある. (スコア:0)
Re:ソースコードの書き方にも問題がある. (スコア:0)
> コンパイルしたとき、スタック上に実行コードを乗っけて、そこに分岐する、
> という野蛮な実装は他の CPU ではどういうコードに落ちるんでしょう。
関数の中で関数を定義しても、スタック上に実行コードなんて生成されましたっけ?。単にテキストセグメントに展開されて、関数のエントリの
Re:ソースコードの書き方にも問題がある. (スコア:0)
{
void inner() {}
printf("%p\n", inner);
}
コンパイルしてアセンブリ見てみ。
Re:ソースコードの書き方にも問題がある. (スコア:0)
プラスモデしてしまうのだな。
Re:ソースコードの書き方にも問題がある. (スコア:1)
# grub も lilo もダメになるんだったら 3.4.x 系列への移行やめるかな...
# まあ試せばすぐ分かることですが。
Re:ソースコードの書き方にも問題がある. (スコア:1)
>コンパイラのバグに引っかかるという見方も出来ると思います.
そうなんでしょうか?
世間のユーザはあまり使わないかもしれない(^^;けど、一方で、
それをわざわざ開発した開発者諸兄は、熱心にテストするかもかも。
#職場で、annotateを見れば見るほど、彼らを信用できなくなってくるのでG7
Re:ソースコードの書き方にも問題がある. (スコア:1, すばらしい洞察)
の時点で、一部のLinuxユーザが大好きな「大勢で使えばバグが減る」法則が適用できないですね。
Re:ソースコードの書き方にも問題がある. (スコア:1, 参考になる)
て、識別子の有効範囲規則はそのために存在していました。Pascal, PL/I, Ada ...
むしろ、C言語の仕様が手抜きではないでしょうか。手続きが入れ子にできなければ、
実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができる
ということでしょう。
Think Pascalで、コールバック手続きを内部手続きにしておくと、大域変数を別途
宣言する必要がなくて、非常に便利だったのを覚えています。
Re:ソースコードの書き方にも問題がある. (スコア:3, 参考になる)
> 実行時に静的リンク/ディスプレイが不要になるため、実行時環境の手抜きができる
> ということでしょう。
手続きの入れ子がなくても、C の機能に限定しても、ソース分割で充分な気がします。
今日ではクラスによる分離、名前空間の方が有効だと思います。
実際に、分割コンパイルができる Turbo Pascal では、入れ子が深くなって
読みにくくなるのを避けるため、分割単位でのローカルな手続きを使っていました。
大域変数も、分割単位のスコープのローカル変数に閉じ込められました。
gcc の nest function は、GNU Pascal の副産物のように聞いていますが、
地雷には違いないようですね。
Re:ソースコードの書き方にも問題がある. (スコア:0)
実行時環境とは何の関係もありませーん。スタティックリンクを含めたアクティベーションレコードやディスプレイをセットアップするのはコンパイラのお仕事です(スタティックリンクを含めてアクティベーションレコードをきちんとセットするようなコードを生成する訳ですから)。つまり、Cはコン
Re:ソースコードの書き方にも問題がある. (スコア:0)
grubのソースを弄れば問題ないのか、特殊な関数定義をしなきゃいけない理由があるのか。
確かGentooは既に~x86で3.4に移行している人がいるはずなんだが
grubがどうこうという話は聞かないし。
エロい人もっと詳細求む。
Re:ソースコードの書き方にも問題がある. (スコア:1)
まだ、-*です。
---にょろ~ん
Re:ソースコードの書き方にも問題がある. (スコア:1)
---にょろ~ん
Re:ソースコードの書き方にも問題がある. (スコア:1)
KEYWORDSに~x86 が入ってますが、
gcc-3.4.1.ebuild:KEYWORDS="-* ~mips -hppa amd64 ~ppc64 ~x86"
[-*]があるので、すべてを否定=>実質無効化されてます。直接ebuildを指定すればインストール出来なくはないですが。。。(たしか。KEYWORDS変数を再設定いるかも)
---にょろ~ん