C/C++言語でスタック領域に確保されるメモリのポインタについて

Question

質問内容

スタック領域に確保されたメモリのポインタを外部に渡すのは危険だと思うのですが
とあるライブラリで下記のような関数(doSomething)を見かけました。問題ないものでしょうか？

危険だと思ったコード

引数で受け取った文字列をローカルの配列(local_name)にコピーし、その配列のポインタをfoo構造体の変数nameに入れています。

struct bar* global_bar = nullptr;

void doSomething(const char *name) {
  char local_name[1024];
  strcpy( local_name, name );
  struct foo = {0};
  foo.name = local_name;
  struct bar* b = create_bar(&foo);
  global_bar = b;
}

local_nameの内容はスタック領域に存在するのでdoSomethingを抜けた時点で不定となるため foo.name = local_name は危険だと思うのですがその認識であっていますでしょうか？

このような場合は create_bar() 内で改めてヒープ領域にメモリを確保してそこにnameの値がコピーされていると考えればよいでしょうか。(もちろんそれは create_bar() 次第なので知るか！と思われるかもしれませんがその関数のドキュメントでは何も言及されていません。)

ただ、不思議なのはもし create_bar() 内で改めてメモリが確保されるのであればdoSomething()内で local_name 配列なんてわざわざ用意せずに foo.name = name というように doSomethingの引数のnameのポインタ値を直接代入してしまえばよいと思うのです。

私のc/c++歴は1ヶ月程度ですので全く不可解な質問であればすみません。

(尚、char local_name[1024] はスタック領域に確保されるとしてください。)

以上、よろしくお願いいたします。

Comments

[Zuishin]

create_bar で文字列を破壊しているならコピーが必要です。

[guriguri]

やはりそうなのですね。ありがとうございます！

[Zuishin]

いや、この処理が正しいと仮定した上でその理由の一つを考えてみただけなので、実際にはこれだけではわかりません。

Answer 1

一般的には、スタックに確保されたデータをその関数外で使用するのは NG。

ただ、ここでは、create_bar()が何してるか不明なので、判断不能と思います。

どうしても気になるなら、デバッガで追跡するなり、それぞれのアドレスを出力して確認されたら、どうでしょう。

Comments

[guriguri]

ありがとうございます！

Answer 2

struct bar* b = create_bar(&foo);

で、ローカル変数のアドレスを返していなければそんでいいです。

関数からの戻り値で、ローカル変数のアドレスを返すとダメです。

Comments

[guriguri]

ありがとうございます！

Answer 3

本質ではありませんが念の為。

おそらくローカル変数のメモリ領域を当該関数外でアクセスしてはいけないという意味だと思いますが、これは「スタック領域だから」ではありません。単純に「当該関数の外では無効な領域だから」です。

ローカル変数は大抵スタック領域に置かれますが、これはコンパイラやOSの都合上の結果的なものです。別にヒープ領域にローカル変数を置いたとしても違反ではありません。

そもそもC/C++ではスタック領域とかヒープ領域とかを選択できるわけではありませんし、全てのコンピュータにスタックやヒープという概念が存在しなければならない理由もありません。ただ単に、WindowsやLinuxの性質上「ローカル変数はスタック領域に置かれることが多い」だけです。仕様上の決まり事ではありません。

Answer 4

こんにちは。

このような場合は create_bar() 内で改めてヒープ領域にメモリを確保してそこにnameの値がコピーされていると考えればよいでしょうか。

create_bar()が適切に動作するための１つの方法と思います。他にも可能性はありそうですが、おっしゃる通りcreate_bar()の中身が分からないとなんとも言えません。

ただ、不思議なのはもし create_bar() 内で改めてメモリが確保されるのであればdoSomething()内で local_name 配列なんてわざわざ用意せずに foo.name = name というように doSomethingの引数のnameのポインタ値を直接代入してしまえばよいと思うのです。

基本的にはその通りと思います。ただし、foo.nameがchar*型だった場合、char const*をコピーできないので、苦し紛れにそのようなコードを書いた可能性もありそうです。
constを使いこなすためには、常にconstかどうか意識してコーディングする必要があるので、意外にそのようなハマり方することが少なくないです。

Comments

[guriguri]

一つ質問させていただきたいのですが、もし仮にdoSomething()メソッドがあるクラスのstaticメソッドだった場合はどうなのでしょうか？
そのメソッド内で確保されたスタック領域であってもやはり関数を抜けた際に不定となるのでしょうか？

[Chironian]

staticメソッド、非staticメソッド、どちらでも同じです。
どちらの関数の場合でも関数内の非staticなローカル変数はスタック上に確保されますから、関数からreturnする際に開放されます。

[guriguri]

ありがとうございます！

Answer 5

もちろんそれは create_bar() 次第

答えをご自身で書いていらっしゃる．
create_bar()の仕様について調べるとか，doSomething()を書いた人に訊くとかするしかないです．
create_bar()が何なのかを知らない相手に訊いても意味ないです．

コードの怪しさ(?)の観点において，質問文ではlocal_nameにばかり言及されていますけど，

foo.name = local_name;
struct bar* b = create_bar(&foo);

というコードの表面的な部分だけ見れば，fooだって同様に疑わしいですし，

global_bar = b;

なんて記述もdoSomething()が呼ばれる度にリークしまくっているようにも見えますし…

何故わざわざ一旦local_nameにコピーするのか？　というのも，
create_bar(&foo)が仕様として「foo.nameの指す先がサイズ1024なバッファであることを期待しているから」とかなのかもしれませんし，あるいは，
create_bar()が「何らかの情報をfoo.nameの指す先に書込み得る(constなバッファじゃダメ)」という理由なのかもしれません．
または，create_bar()はfoo.nameに書込を行わないとしても，foo型というのが別の関数でも使う型で，そっちでは出力先として使うのかもしれません．（ReadInfoFrom(const foo*)とWriteInfoTo(foo*)みたいな．）

Comments

[fana]

ん？
create_bar()で生成される(と思われる)barが，引数で渡されたポインタ(local_name)を保持するような話なのかと思ったが，
質問文をよくよく見れば，そんなこと全然書かれてないじゃないか．
それなら，別に見た目には何の問題もなくね？