allocaはどうやってスタックからメモリを確保するのか？
How do functions like alloca allocate memory from the stack?
コンパイラが大きなスタック割り当てを行う際にガードページをスキップしないようにする仕組みについて、以前の記事で解説しました。今回は、_alloca関数が同様に__chkstk関数を呼び出してスタックをプローブし、スタックポインタを調整することを、x86-64アセンブリの例を使って説明します。ローカルフレーム作成時とalloca()の両方で同じ__chkstkが使われる点がポイントです。
同じ__chkstk関数が、ローカルフレームを作成する際の初期スタックプローブと、alloca()の両方で使用されていることに注目してください。
HNでの議論
65- rramadass
上記に関連して、スタックに関して知っておくべき重要な概念が2つあります。「レッドゾーン」と「ガードページ」です。
またレイモンド・チェン氏の記事：
なぜレッドゾーンを定義する必要があるのか？スタックを何にでも使ってはいけないのか？ - https://devblogs.microsoft.com/oldnewthing/20190111-00/?p=10...
スタックガードページの詳しい解説 - https://devblogs.microsoft.com/oldnewthing/20220203-00/?p=10...
- uecker
誰もallocaを使うべきではありません。スタック上にバッファを確保する必要があるなら、VLA（可変長配列）を使いましょう。VLAは標準化されており、適切なスコープに基づく寿命があり、正確なサイズを記憶する型を持っています。ええ、MSVCがVLAをサポートしていないことは知っています。そんなコンパイラは使わないでください。（功績を認めるべき点として、MSVCはGCCやclangよりずっと早くスタックプロービングを実装していました。clangはかなり遅かったです。）
GCCでは、-fstack-clash-protectionを使うとスタックプロービングが有効になります。これは_chkstkに似ていますが、GCCはスタックプローブをインライン展開します。
VLAはスタッククラッシュ攻撃のせいで悪い評判を得ましたが、スタッククラッシュ保護がないと、VLAがなくてもこれらの攻撃は発生し得ます（実際、最初のそのような攻撃は固定サイズの配列を悪用したものです）。そして、この保護を有効にすれば、VLAを避ける理由は私の意見ではあまりありません。
小さな可変サイズのバッファが必要な場合、VLAはほとんどの代替手段よりもほぼ常に優れています。allocaはあらゆる点で劣っています（上記参照）。最悪ケースの境界を持つ通常の配列は、VLAと比較してスタック使用量を増やし、正しい動的サイズをエンコードしないため境界チェックが弱くなります。また、バッファをヒープに移すのは遅く、コードを複雑にします。
スタックに置くもののサイズを適切に把握できず、VLAが制限を超えることを心配する場合（繰り返しますが、最悪ケースのサイズの通常の配列はVLAと比較してスタック使用量が増えます）、GCCでは-Wvla-larger-thanを使用して各VLAのサイズが制限内に収まるようにすることができます。
- jacknews
ほんの少し関連した話ですが、17歳の息子によるRustのスタック割り当てに関する面白い狂気を紹介します：
- pjmlp
標準Cでは実際には実装できない関数の一つで、コンパイラのサポートか、スタックレジスタ操作用の純粋なアセンブリで書く必要があります。Cの「マイクロランタイム」機能の一つです。
UNIX第7版からC99まで、VLAが導入されましたが、C11でオプションになり、C23の更新でも自動VLAはサポートされず、関数パラメータのみで、結局この指摘は正しいままです。
- kjellsbells
私が少し怖いと思うことの一つは、25歳から40歳くらいの若い開発者で、Windows内部の達人の役割を引き継ぐことができ、かつ引き継ぎたいと思っている人がいるかどうかです。
つまり、チェン氏は数十年分のWindows内部知識を頭の中に持っています。マイクロソフトは何年も人員を削減してきました。PetzoldやChenの世代が引退するとき、マイクロソフトにはまだ、Windowsをハードウェアのレベルから理解している人々が十分に残っているでしょうか？