13

私はStevensPosix Programmer's Guideを調べましたが、私が見つけることができる最高のものは

プロセスが開始されると、 environmentと呼ばれる文字列の配列が使用可能になります。この配列は、次のenvironように定義される外部変数によってポイントされます。

extern char **environ;

私が躊躇しているのは、その環境変数です。私は言いたい

-呼び出し元のプロセス/シェルは、null で終了する文字列のブロックを既に割り当てています

-「外部」変数はgetenv()environによってエントリ ポイントとして使用されます。

-事実上、静的イニシャライザ内でgetenv()を自由に呼び出してください。

しかし、環境の「静的初期化」が他のすべての静的初期化コードに先行するという保証は見つかりません。私はこれを考えすぎていますか?

アップデート

私のプラットフォーム (AMD Opteron、Redhat 4、GCC 3.2.3) では、LD_DEBUG設定すると、静的初期化子が呼び出される前に、 environが設定されることが示されます。これは知っておくと便利です。ありがとう、@コードロジック。しかし、必ずしもすべてのプラットフォームで得られる結果ではありません。

また、C/C++ ランタイム ライブラリの動作について @ChrisW に直感的に同意しますが、これは経験に基づく私の直感にすぎません。したがって、静的イニシャライザが呼び出される前にEnvironが存在することを保証する信頼できる場所からの引用をパイプできる人は誰でも、ボーナスポイントです!

4

3 に答える 3

4

環境のセットアップと静的初期化子の呼び出しの両方が main() が呼び出される前に言語ランタイムが実行する必要がある関数であることを考えると、ここで保証が見つかるかどうかはわかりません。つまり、これ機能する必要があり、たとえば ANSI 言語やライブラリ仕様などで main() の前に順序が保証されているという特定の要件を認識していません....しかし、私はチェックしませんでしたどちらかを確認します。

同時に、どのランタイム ライブラリ関数を静的初期化子から呼び出すことができるかを制限する特定の要件については知りません。さらに言えば、ある環境から環境にアクセスできなければ、(私にとっては) ランタイム バグのように感じられます。

これに基づいて、私はこれが機能すると予想することに投票します。これは安全な仮定であり、現在のデータポイントはこの推論をサポートしているようです.

于 2009-01-13T01:13:40.967 に答える