アカウント名:
パスワード:
私なりにこの問題点を説明させていただきます。間違っていたらごめんなさい。結論から言うとメモリ領域を本来の意味から逸脱した状態で使っている瞬間があるからだと考えています。
スタックは下に向かって伸びていくとしますので、スタックポインタより上が使用中、下が未使用と考えてください。
1.addressee()に入った時にresultはスタック上に確保され初期化される。
+--------------+|return address|←addressee()を呼び出した場所への戻り+--------------+|<-result || a[world\0] |+--------------+←スタックポインタ
2.addressee()で使った領域を破棄し呼び出し元に戻る。
プログラムを変えちゃったら言語仕様の話にも、コンパイラの実装方法の話にも、根本原因の話にもならないじゃないですか。
たぶん現行仕様での対応方法は皆判っていて、その上で自動変数の扱いをどの様に拡張したらC++の様に使えて、この様な使い方が誤りでなくなるのかと言う悩みだと思います。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
単なる使い方の誤りではないですか (スコア:1, すばらしい洞察)
私なりにこの問題点を説明させていただきます。間違っていたらごめんなさい。結論から言うとメモリ領域を本来の意味から逸脱した状態で使っている瞬間があるからだと考えています。
スタックは下に向かって伸びていくとしますので、スタックポインタより上が使用中、下が未使用と考えてください。
1.addressee()に入った時にresultはスタック上に確保され初期化される。
2.addressee()で使った領域を破棄し呼び出し元に戻る。
Re: (スコア:1)
addressee を内部的に次のような形に変形し、
void addressee(struct X *r) {
struct X result = { "world" };
*r = result;
}
呼び出し側が代入先オブジェクトへのポインタをこっそり渡せば
きちんとスタック内で完結するコードを生成可能だからです。
実際 cygwin の gcc (GCC) 4.3.4 20090804 (release) 1 はそのようなコードを生成しました。
問題は呼び出し側がどう一時変数を用意するかという点にあります。
例えば次のような関数呼び出しが
不具合の修正方法の話をしている訳ではないと思います (スコア:0)
プログラムを変えちゃったら言語仕様の話にも、コンパイラの実装方法の話にも、根本原因の話にもならないじゃないですか。
たぶん現行仕様での対応方法は皆判っていて、その上で自動変数の扱いをどの様に拡張したらC++の様に使えて、この様な使い方が誤りでなくなるのかと言う悩みだと思います。
Re:不具合の修正方法の話をしている訳ではないと思います (スコア:1)
「元AC(#1972743)で述べられているスタック操作がおかしい」
という話をしたつもりでした。
つまりコンパイラの実装方法の話です。
「スタックポインタの下は揮発性」という環境下で
「addressee がスタックポインタの下を指すポインタを返す」というコードを吐くコンパイラは
間違ってるのではないかと思います。