アカウント名:
パスワード:
ノイマン型コンピュータの基本構造は、その頃の発想から、実質まるで変わっていないし、変えたくても、互換性維持のためには変えられなかったのが、おそらく実情。
高級言語での保護も、言語レベルでの保護を捨てたCが普及してしまい
プログラミングの発想を根本から変える可能性のあったPrologや、第五世代も滅んだ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
ハッカーとクラッカーの違い。大してないと思います -- あるアレゲ
要するに (スコア:1)
欠陥アーキテクチャのCPUを使ったシステム(Windowsに限らず)に
依存しているこの世の中って？？？？
スタックオーバーフローなんて、OS/コンパイラー以前に
システム設計時につぶせるものだと思うのですが...。
^-_^-_-~
救世主はきっといる。
Re:要するに (スコア:5, 興味深い)
＞システム設計時につぶせるものだと思うのですが...。
歴史的に言えば、サブルーチンは、かつて、自己書換プログラムとして実装されていた。（JMP命令しかなかった）
ノイマン型コンピュータの基本構造は、その頃の発想から、実質まるで変わっていないし、変えたくても、互換性維持のためには変えられなかったのが、おそらく実情。
実際、互換性を維持したまま高速化するの為のアーキテクチャ変更は、高度に進歩している。
OSでは、Multicsで、ハードレベルで複雑かつ高度な保護が考えられていた。が、それは滅びて、
-- Buy It When You Found It --
Re:要するに (スコア:0)
Re:要するに (スコア:0)
アホか。
Re:要するに (スコア:1)
ノイマン型でもハーバードアーキテクチャならバッファオーバーフローによる不正な命令コードの実行なんて事態は絶対に発生しえない。
この問題はノイマン型であることに由来するものではない。
ということでしょ。
個人的には、引数だとかローカル変数というデータ情報とリターンアドレスというコード情報を同じスタックに積むというやり方が最大の問題でしょう。
ハーバードアーキテクチャなんて使いにくいものにしなくても
スタックを2本持ち、
コールスタックの方にはそれ以外の情報は持てないように
すれば簡単に解決しますね。
もっとも、コンパイラの処理内容と呼び出し規約の問題なので、
既存のプログラムとの互換性がまったく持てないのが難点でしょうか?
Re:要するに (スコア:0)
『ハーバードアーキテクチャ』
今日ではこの用語は，単一の主記憶装置を有しているが，キャッシュ・メモリが命令用とデータ用に分離されているマシンを指すものとして使われている。
（ヘネシー＆パターソン著 コンピュータ・アーキテクチャより）
Re:要するに (スコア:1)
「今日では」って所が重要なのですが、
元々、「ハーバードアーキテクチャ」とは、命令用メモリとデータ用メモリが分離しているもの [google.co.jp]を指す言葉です。
今でもDSPとかに見られます。
それを、キャッシュメモリを命令用とデータ用に分離していることを指す言葉にも流用してるだけです。
Re:要するに (スコア:0)
関数ポインタをスタックに積んだりローカル変数に保持するのも禁止ですか？
性質はリターンアドレスとなんら変わりないように思えますが。
Re:要するに (スコア:0)
正気か？
Re:要するに (スコア:0)
スタック上のバッファをオーバーフローさせて
リターンアドレスでもローカルの関数ポインタでも書き換えれば、
不正な命令コードを実行できますね。
任意のコードを実行できるかどうかは分かりませんが。
そういう意味で、次