問題タブ [alloca]

私の意見では、C で構造体の定義を非表示にすると、構造体のメンバーに直接アクセスできないように (コンパイラーの助けを借りて) 強制するため、一般的にコードが安全になります。

ただし、この方法では構造体のサイズが利用できなくなるため、構造体のユーザーがその型の変数をスタックに置くことを宣言できないという欠点があります (したがって、ユーザーは、malloc()望ましくない場合でもヒープを経由します)。

これは、POSIX に準拠しalloca(3)ていなくても、すべての主要な libc 実装に存在する関数によって (部分的に) 解決できます。

これらの長所と短所を念頭に置いて、そのような設計は一般的に良いと見なすことができますか?

でlib.h：

でlib.c：

でexample.c：

構造内で VLA を宣言できるようにする、優れた GCC 拡張機能を使用しています。今のところ、この方法で VLA を関数に (値で) 渡す方法を見つけました。また、非常に限られたコンテキストで返す方法を見つけました。

この例の関数コードは次のとおりです。

上記の例は、テスト目的で設計されています (特に、コンパイルされたバイナリ コードを比較するため)。

ただし、返される配列のサイズは関数の異なる呼び出し間で変化しないため、これはかなり制限されています。

返された配列のサイズを、関数パラメーターの 1 つまたはこの関数の他のローカルと等しくするにはどうすればよいでしょうか。

alloca割り当てられたメモリは関数終了 (IRC) ですぐに破棄されるため、この場合は役に立たないと思います。

私はこのようなものを書きたい：

言い換えれば、疑問符内の型は何でしょうか? または、他の解決策があるかもしれません（ただし、を使用せずにmalloc）？

このような関数の理論的な使用法では、返された構造体のサイズを呼び出し元が利用できないため、返された値を格納するために理論的には別の型が必要になります (これを回避する方法がない限り?)。しかし、一見すると、次のようになります。

このようなことをすると:

func5VM の戻り値の型は、その引数またはローカル変数に依存するため、機能しません。ただし、この関数はまだ定義できないため、現時点ではすべて理論上のものです。

私のstackAlloc関数は次のようになります。

そのように変更すると、すべてが機能する代わりにstackAlloc関数が常に使用されます。mallocalloca

関数をマクロに変更したところ、期待どおりに機能するようになりました。

regerrorエラー メッセージを格納するために必要なバイト数を返します。私が使用しているアプリケーションはスタックに「深く」入っていないため (つまり、深くネストされた関数呼び出しはありませんalloca)、エラーメッセージ用の一時ストレージを取得するために (アプリケーションが既に他の目的で使用している) を使用することを考えていました(ヒープではなく) スタック上。

スタック オーバーフローに遭遇しないように、エラー メッセージ (長さ) が制限されると想定しても安全ですか?

これは (使用されたメッセージ カタログを操作することによって) セキュリティ ホールを開きますか?

GNU libs docs を読むと、次のことがわかります。

一部の非 GNU システムは alloca をサポートしていないため、移植性が低くなります。ただし、C で記述された alloca のより低速なエミュレーションは、この欠陥のあるシステムで使用できます。

alloca()VLAも利用できないと仮定すると、Cエミュレーションはどのようになりますか?

私がインターネットで見つけた C++の唯一のalloca()代替品は、次のようなものです。

しかし、明らかに、これはalloca()私たちが知っていて愛しているものではなく、関数でもマクロでもありません。関数呼び出しalloca()のセマンティクスにより近い実装を記述できますか? alloca()おそらくマクロとして？マクロであろうと関数であろうと、ヒープではなくスタックからスペースを割り当てる必要があります。

関数 _alloca() (malloc.h で定義) を内部的に使用する共有オブジェクト (.so) を構築しています。この .so はスムーズにコンパイルされます。しかし、_alloca() を使用する関数を呼び出すとすぐに、コンソール出力でアプリケーションがクラッシュします。

だから：この外部参照を解決するためにビルド中にリンクしなければならないライブラリに対するアイデアはありますか？

プラットフォームは CentOS7 x64

ありがとう！

alloca()固定サイズの配列を宣言してスタックに割り当てられたメモリよりも適しているのはいつですか?

詳細：

私たちが知っているようにalloca()、物議を醸す関数です。むやみに使用すると、スタック オーバーフローが発生する可能性があります。慎重に使用すると、ヒープの割り当てを回避することで、タイトなループから数ナノ秒短縮できます。なぜが悪いと見なされるのかについてのこの質問では、上位の回答のいくつかが を時折使用することを推奨しています。allocaalloca

スタックから割り当てるもう 1 つの方法は、単純に固定サイズの配列を宣言することです。この戦略の例は、 Howard Hinnant の stack allocator のarenaクラスにあります。(そのコードはもちろん C++ ですが、概念は C にも当てはまります。)

alloca固定サイズの配列とのトレードオフは何ですか? 一方が他方よりも明らかに好ましいのはいつですか？個々の状況 (パフォーマンスが主要な目標であり、ホットスポットが既に特定されている場合) で経験的にテストする必要があるのは、単にパフォーマンスの問題ですか? 固定サイズの配列はより悲観的です。スタックに割り当てたい分だけ常に割り当てますが、これが良いか悪いかは明らかではありません。

できるだけ明確にするためにalloca、固定サイズの配列を使用する理由と思われる 2 つの関数実装の非常に単純な例を次に示します。

非常によく似た別のオプションallocaは VLA です。私の知る限り、allocaと VLA から取得したメモリは本質的に同じ動作をするため、この質問は VLA にも当てはまります。その理解が間違っている場合は、それについて言及してください。