>75 じゃないから、違っているかもしれないけど...

>>76
> 　一度聞いてみたいアイデアなような気がしますので、
> ここでおっしゃる「メモリハンドラ」というものの詳細や、この方式での
> 具体的なファイルアクセスの手順を聞ければ幸いです。

メモリハンドラは、単なるポインタでいいと思う。C で書けば...

File F = fopen("test.txt", "r");
char *p = fread(F, 100);

とかすれば、OS が 100バイトの領域を確保して、そこにデータを読み込んでから、そのアドレスを返してくれるという感じかと...。
C だと、free(p) とかしないとダメだけど、Java とかならそれも必要ないだろうし。これで、fread() が間違ったアドレスにデータを書き込んでしまうことは防げるでしょ ?

> アプリ側が不法なバッファアドレスを指定した場合、fread() API 内部で、
> スーパーバイザ権限で「身代わりアクセス」してしまうことを指摘されて
> いるのですね。

今時、そんなタコな OS は無いでしょう。当然...

> ご存知かもしれませんが、これを防ぐ手は一応存在していて、API の処理冒頭
> で、メモリが合法かどうかをソフト的にチェックするルーチンをかませば、
> 跳ね返せます。

ぐらいはやってはず。そうではなく、fread() に間違ったアドレス指定して、自分で使う領域を壊したりするのを防ぎたいんだと思う。最近のコンピュータウィルスで使われるバッファーオーバーランとかを避けたいだけじゃないでしょうか。

> CPUの保護機能だけでは無理で、通常のCPU命令を用いてページテーブルや
> セグメントの属性やフラグ類をチェックしなければならないので、確かに
> 煩わしいのですが。

プロセサによっては、保護機能を使えるのもありますよ。(68K の moves とかね。)