質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

88.80%

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

解決済

回答 5

投稿 編集

  • 評価
  • クリップ 1
  • VIEW 577

guriguri

score 34

質問内容

スタック領域に確保されたメモリのポインタを外部に渡すのは危険だと思うのですが
とあるライブラリで下記のような関数(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] はスタック領域に確保されるとしてください。)

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

質問への追記・修正、ベストアンサー選択の依頼

  • Zuishin

    2020/03/01 18:14

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

    キャンセル

  • guriguri

    2020/03/01 18:25

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

    キャンセル

  • Zuishin

    2020/03/01 18:31

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

    キャンセル

回答 5

+3

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/03/01 18:25

    ありがとうございます!

    キャンセル

+2

struct bar* b = create_bar(&foo);

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/03/01 18:25

    ありがとうございます!

    キャンセル

+1

こんにちは。

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/03/02 00:58 編集

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

    キャンセル

  • 2020/03/02 14:09

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

    キャンセル

  • 2020/03/03 04:59

    ありがとうございます!

    キャンセル

+1

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

checkベストアンサー

0

もちろんそれは 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*)みたいな.)

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2020/03/02 14:20

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 88.80%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る