アカウント名:
パスワード:
こういう騒ぎを見るとさすがにCは古いと思ってしまう大昔と違ってプロセッサの処理能力はジャブジャブあり余っているのだから、厳密な型変換を強制されたり、デフォルトで配列の境界チェックをするような言語・コンパイラをみんなが使えば良いのに............そういう言語・コンパイラの仕様に合わせた型チェックなどのための機能を持つプロセッサがあっても良いだろうし...........(まあ今あるもの変えることなど不可能だし、再び高級言語マシンの夢を見ること自体が古いと言われればそうだが)
しかし、その言語・コンパイラ(及びランタイムの実行環境とライブラリ)を書くための言語は、めぐりめぐって最終的にはCになるんではないでしょうか。で、そのランタイムの実行環境とライブラリに脆弱性が見つかると。JavaとAcrobat Readerのことですが。
その言語のコンパイラを、その言語自身で書くというgcc方式でいいんじゃないですか?
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
皆さんもソースを読むときに、行と行の間を読むような気持ちで見てほしい -- あるハッカー
古い言語・コンパイラ (スコア:0)
こういう騒ぎを見るとさすがにCは古いと思ってしまう
大昔と違ってプロセッサの処理能力はジャブジャブあり余っているのだから、厳密な型変換を強制されたり、デフォルトで配列の境界チェックをするような言語・コンパイラをみんなが使えば良いのに............
そういう言語・コンパイラの仕様に合わせた型チェックなどのための機能を持つプロセッサがあっても良いだろうし...........
(まあ今あるもの変えることなど不可能だし、再び高級言語マシンの夢を見ること自体が古いと言われればそうだが)
Re:古い言語・コンパイラ (スコア:0)
しかし、その言語・コンパイラ(及びランタイムの実行環境とライブラリ)を書くための言語は、めぐりめぐって最終的にはCになるんではないでしょうか。
で、そのランタイムの実行環境とライブラリに脆弱性が見つかると。
JavaとAcrobat Readerのことですが。
Re: (スコア:0)
その言語のコンパイラを、その言語自身で書くというgcc方式でいいんじゃないですか?