>>438
パラグラフ１の意味するところが
ハードウェアの提供するプログラムスタックでも、コンパイラあるいはランタイムの生成した
ソフトウェアスタックでもないそれ以外のものを独自実装するっちう意味なら、ちと賛同しかねる。
ハードやOS依存の手続きが必要になるので標準Cから大きく外れるやん。


> 実際のところ、リターンアドレスまで入っている場所を
> バッファオーバーフローをチェックしない言語の変数
> 領域として使うというのは危ない設計のように思える。

あと、これもちょっと違う希ガス

変数どこに置くか云々の問題じゃないと思う。
たとえばレジスタにヒープ領域のアドレスを入れ、ヒープに引数リストを置く、とかやったとしても、
結局はスタック上にリターンアドレスが置かれるわけで、バッファオーバーランによる
リターンアドレス書き換えの問題は解決のしようが無い希ガス。

【こんな風にデータが並んでますよの図】
バッファ→
■■■■■■■■■■□□□□□□
□□□□□□□□□□□□□□□□
□□□□□□□□□□□□□□□□
□□□□□□■■■■■■■■■■
　　　　　　　　　　　　　　　←スタック

VC++はコンパイルオプションでバッファオーバーランを検出するCookieを設定できたと思う。
最近はハードやOSレベルでも保護機能(DEPとかNXとかXDとかいうやつ）実装してるし。