問題タブ [stackalloc]

stackalloc の C# リファレンスから:

stackalloc を使用すると、共通言語ランタイム (CLR) のバッファー オーバーラン検出機能が自動的に有効になります。バッファ オーバーランが検出された場合、悪意のあるコードが実行される可能性を最小限に抑えるために、プロセスはできるだけ早く終了します。

具体的には、.NET にはどのような保護メカニズムが実装されていますか?
また、バッファ アンダーランも検出しますか? どの既知の攻撃に対する保護が弱いですか?

コンテキストについては、たとえば MS C++ コンパイラの場合、情報は次の場所で入手できます:
Windows ISV ソフトウェア セキュリティ防御:

スタック バッファ オーバーラン検出機能は、Visual Studio .NET 2002 で C/C++ コンパイラに導入され、その後のバージョンで更新されました。/GS は、関数のスタックに配置される乱数を生成およびチェックするために、スタートアップ コード、関数のエピローグおよびプロローグ コードを追加するようにコンパイラに指示するコンパイラ スイッチです。

Visual C++ 2005 (およびそれ以降) も、スタック上のデータを並べ替えて、そのデータが予測どおりに破損しにくくすることに注意してください。例 を以下に示します。
• バッファを非バッファよりも上位のメモリに移動する。この手順は、スタック上に存在する関数ポインターを保護するのに役立ちます。
• さまざまなバッファ オーバーラン攻撃を軽減するために、実行時にポインタとバッファ引数を下位メモリに移動します。

stackalloc をいつ使用するかについて、以前の StackOverflow の投稿から例を読みました。さて、この例は私を少し当惑させました:

私はまだ C# とプログラミング全般の初心者なので、間違っている場合は遠慮なく訂正してください。しかし、バイトは値型ではありませんか? また、値型は宣言された場所に格納されていませんか? これは、この例でmanagedは もスタックに格納されているということではないでしょうか。拡張により、このスタック フレームが終了し、呼び出しアドレスに移動すると、メモリは自動的にクリーンアップされるため、これmanagedと同じ方法で削除する必要があります。unmanaged例？

stackalloc以下のような参照型で使用される場合

エラーがあります

アドレスの取得、サイズの取得、またはマネージ型 ('string') へのポインターの宣言はできません

どうしてですか？CLRマネージド型へのポインターを宣言できないのはなぜですか?

「stackalloc」キーワードが可変長を受け入れる理由は何ですか?

この命令がスタックのフレームに割り当てられたバッファへのポインタを返す場合、コンパイラはそれをどのように管理しますか? スタックフレームを整理するために呼び出されるたびに、実行時に関数を再コンパイルしますか?

ありがとう。

文字列を操作する C++ コードと対話する C# コードがあります。

静的ヘルパー クラスに次のコードがあります。

ご覧のとおり、stackallocキーワードで作成されたバイトへのポインターを返します。
ただし、C# 仕様 18.8 から:

関数メンバーの実行中に作成されたすべてのスタック割り当てメモリ ブロックは、その関数メンバーが戻るときに自動的に破棄されます。

メソッドが戻るとすぐにポインターが実際に無効になるということですか?

メソッドの現在の使用法:

コードを次のように変更する必要があります

メソッドfixedにポインターを渡すために、返された配列を再度使用しますか?DirectFunction

使用回数を最小限に抑えようとしています(およびofの他のオーバーロードのステートメントをfixed含む)。fixedGetByteCount()GetBytes()Encoding

tl;dr

1. メソッドが戻るとすぐにポインターは無効になりますか? に渡された時点で無効DirectFunction()ですか？

2. fixedもしそうなら、タスクを達成するために最も少ないステートメントを使用する最良の方法は何ですか?