- 締切済み
C言語で、メモリを解放しないで終わるプログラム
Ｃ言語の話です。 mallocなどで領域を確保したら、解放しなければいけないんですよね。 しかし、解放しないで終了すると具体的にどうなるのか、私は理解していません。 次のような、freeしないプログラムを作って何回か実行してみました。しかし、別におかしくならないですね。 #include <stdio.h> #include <string.h> #include <stdlib.h> char *cp; int main(void) { unsigned int n; printf("サイズ（２以上）を入力してください:"); scanf("%d",&n); cp=malloc(n); if(!cp) { printf("%s\n","mallocできませんでした。"); return(1); } strcpy(cp,"A"); printf("cpは%sです。\n", cp); printf("それでは終わりにします\n"); return(0); } グローバルでcharの固定長の配列を宣言したとすれば、プログラムの終了時にその領域は解放されると思います。 このような固定長の配列の場合とmallocの場合との違いが問題なんです。 実験的に、解放しないがために何かおかしくなってしまったり、悪影響を及ぼしたりするようなプログラムを作りたいんですが、どのようにすればよいでしょうか。 もしも私の環境ではそのようなプログラムが作れないなら、別の環境の話でもよいので具体的にこんなふうになってしまうという話をお聞きしたいんです。 過去の質問を検索してみました。 http://oshiete1.goo.ne.jp/kotaeru.php3?q=160037 ここのNo.9では、「freeしないアプリケーションの起動・終了を繰り返すと、リソースが不足する」旨が書かれていて、質問者の方もそれで納得されているようです。 しかし、私は、リソースが不足するとはどういうことで、何が起こるのか、知りません。 私のマシン ＯＳ：Windows98ＳＥ ＶＣ＋＋6.0
- C・C++・C#
- 回答数10
- ありがとう数12
- みんなの回答 （10）
- 専門家の回答
みんなの回答
＞Ｃ言語でのＡＮＳＩ規格やＫ＆Ｒによる「Programing ＞C」においても「アロケートしたメモリはfreeすること ＞で開放する」となっています。本書もこれらと同じ立場 ＞です。 ＞ ＞（３）で言っているのは、「freeすることで解放する ＞んだ。プログラムが終了することで解放するなんてい ＞うことは規格にはないぞ。」ということでしょう。 ・「Ｋ＆Ｒ」は書式の規格であり動作を表すものでは ありません。 ・Ｃ言語のメモリ管理はプログラム動作中の話であり、 終了後の処理を規定するものではありません。 ・メモリリークはＯＳの問題です。 わからんことは自分で書いてね。別に誰も困らないから。
- toysmith
- ベストアンサー率37% (570/1525)
> mallocによってＯＳから借りたメモリは、 > 必要がなくなった時点でfreeにより、 > ＯＳに返すのが、Ｃ言語でのルールです この表現は明らかな間違いを含んでいます。 ・freeはOSに領域を返却しない マンションの例えを続けます。 マンションが満杯のときに新しい入居者があった場合、mallocはマンション自体を建て増しするようなカンジで未割り当て領域自体を拡張するような実装は存在します。 このとき、OSに新しい領域を要求するか否かは実装依存です。 しかし、freeは「未入居」とマークをつけて新たな入居者の受け入れ準備をするだけで、マンションの取り壊しは行いません。 そんなことをするとmalloc/freeの連続によってシステムに強烈な負担を強いることになります。 （仮想記憶システムではページングが発生するため、システム全体の運用が中断する可能性がある） ・そもそもmallocがOSから領域を借用している保証は無い mallocがOSから領域を借用するかどうかは実装依存です。 通常はアプリケーション領域のヒープ領域から割り当てが行われるので、mallocがOSに働きかけるような実装はほとんど存在しません。 mallocがシステムコール扱いであるようなシステムならありえることですが、C言語のライブラリに依存するようなシステムコール体系のOSなんて存在しないでしょう。 WindowsのGlobalAllocのようなシステム依存のメモリ割り当て関数ならOSに働きかける可能性があります。 ・「C言語のルール」が意味不明 C言語の体系は多岐にわたりますが、初代のC（UNIX上のRitchie-C）および2代目のC（いわゆるUNIX-CであるJhonson-C）ではここでいう“ルール"は通用しません。 （UNIXと言うOSがmallocをシステムコール扱いしていないため） また、ANSI-C/Hosted Environmentでは先に書いた理由でOSからのメモリ割り当ての可能性はほとんどありません。 ANSI-C/Free Standing EnvironmetにおいてはOSの存在を想定していないので、全く当てはまりません。 WhiteSmith-Cなどの（現在では駆逐されてしまった）方言色の強い実装ではありえる話ですが、1989年以降はルールと呼べるほど一般的ではありません。 ANSI-Cと一口に言ってもHosted EnvironmentとFree Standig Environmentでは全く違った構成になります。
欠けている２つ目ＵＲＬ といってもたいしたモンではないが
お礼
参考ＵＲＬのほう、よく読んでみます。
＞「質問のソースで、多くのサイズをmallocさせれば、ＯＳが ＞フリーズする」とおっしゃっていますか？ ＞それとも、 ＞「質問のソースでは、たとえどれだけ多くのサイズをmallocしても、 ＞ＯＳのフリーズは起きない。」とおっしゃっていますか？ あなたは、まずどちらだと思いますか。 回答では、前半部分では容量の話、後半部分では開放タイミングの話を しています。『多くのサイズ』かつ『終了させないこと』がそのソースで リークを確認する条件です。 そもそも答えはひとつしかありません。 そこまで追求ができるのであれば、既にある程度理解なさっていると 思われます。把握できた時点で『よし』としてもらいたいんですけど・・・ では順番に ＞「mallocしてfreeせずにプロセスが終了す ～ 反応しなくなってしまう。」 プロセス終了時には解放されます。プロセス終了時にも解放されないのは リソースリークです。 ＞リソースメータというのは、どこにありますか？ Win98 ならスタートメニューから「プログラム」「アクセサリー」 「システムツール」「リソースメータ」にあります。なければＣＤ－ＲＯＭ からインストールして下さい ＞この話はアプリが終了しないで継続して実行するときの話ですよね。 メモリリークの注意とはそもそもそういう状況の話で行います。 main() 関数ひとつだけのアプリケーションでは質問に対する回答を 話していくのが難しいのです。 ＞リソースリークというものはどのようにすれば起きるのでしょうか。 ＞どのようなソースならばそれが起きるのでしょうか。 私は、あなたが検索した過去の質問のどの部分に納得いっていないのかを 知らないのです。ひとことで『どのようなソース』と言っても、あなたの 現在の知識範囲がわからないので答えようがないのです。一応書くだけ 書きます。 Windowsプログラミングでは Win32API というものを使います。その際 リソースハンドルという概念であらゆるＯＳ資源にアクセスします。 そして使用後解放を行います。 例えばビットマップを利用するときには HBITMAP hBmp = CreateBitmap( ・・・ ); ～ DeleteObject(hBmp); のようにコーディングしますが、このときの DeleteObject() を行わないと ・ハンドル（個数） ・使用メモリ の２つがリークします。これらはＯＳ上の全システム共通に一意管理されて いるので再起動するまで取り戻すことは不可能です。 その他 参考ＵＲＬもどうぞ ・・・・・・・・・ 一応メモリリークソースです。見たままです。 int main() { char* p; while(1) p = malloc(3000000); return 0; } 最後に・・・ 何を欲しているのかがいまひとつピンときません。『解放できないと 具体的に何が起こるのか』という質問だったと思うのですが。 どうも禅問答の類は苦手です。とんちの利くような機転は持ち合わせて いませんので。。
お礼
ありがとうございます。
- toysmith
- ベストアンサー率37% (570/1525)
書き忘れましたのでもう一度。 malloc/freeを１セットで考えている人がいるようですが、「プログラム終了時にすべてをfreeする」なんていう処理は愚の骨頂です。 malloc/freeはマンションの内装工事のようなものです。 mallocは次の入居者のために内装工事を行います。 freeは次の入居者のための回復工事です。 マンション自体の取り壊し（＝プログラムの終了）が行われる寸前に回復工事の必要はありません。 動的メモリ領域を10000個くらい確保して、freeして終了する場合とfreeせずに終了する場合を比べてみてください。 プログラム終了寸前にfreeするのは無駄以外の何者でもありません。
お礼
このマンションのたとえくらい優しく説明されると、よくわかります。
- toysmith
- ベストアンサー率37% (570/1525)
ANSI-C規格の範囲で考えます。 よって、ここでいう「動的メモリ」はmalloc,realloc,callocで確保されたものに限定されます。 ANSI-C準拠の処理系ではプログラム終了時に動的確保されたメモリ領域はすべて開放されなければなりません。 これは、プログラムの終了方法（main関数でのリターン、任意の場所でのexitなど）にかかわらず必ず開放されなければなりません。 たとえ、強制終了であっても何らかの方法で動的メモリが開放されることが前提です。 よって、動的にメモリを確保してままプログラムが終了しても何の問題も起こりません。 問題が起こるのはむしろ「プログラムが終了しない場合」です。 サーバーソフトウェアなど、プログラムが終了しないまま連続稼動していると確保され続ける動的メモリ領域は膨大な量になり、最終的にはメモリ不足を引き起こします。 また、仮想記憶システムではスワップシステム（ページ管理テーブルやディスク上のスワップ領域自身）を圧迫します。 Windows特有のリソースの圧迫を心配されているようですが、Windowsの一般的な処理系におけるANSI-Cの動的メモリ確保関数はWindowsのユーザリソース、GDIリソースを消費しません。 よって、malloc/freeの呼び出しとリソースの不足は何の関連ももちません。 そもそも、mallocがOSからメモリを提供されている保証はなく（mallocの実装方法は処理系依存のため）、たとえmallocがOSから領域を提供されていてもfreeがOSに返却することはほぼありません。 freeは「再利用できるようにする」という関数であり、返却はfreeの機能範囲に含まれません。 メモリ領域をOSに返却するのはプログラム終了時だけです。 よって、freeのある／なしは終了したプログラムのメモリリークに関連することはありえません。 多分、APIなどANSI-C標準関数以外の動的メモリ操作関数と混同されているのではないでしょうか？
補足
>ANSI-C規格の範囲で考えます。 >よって、ここでいう「動的メモリ」はmalloc,realloc,callocで確保されたものに限定されます。 そうですね。私の場合、この質問の問題は、範囲を限定して考えたほうがよさそうです。 > >ANSI-C準拠の処理系ではプログラム終了時に動的確保されたメモリ領域はすべて開放されなければなりません。 >よって、動的にメモリを確保してままプログラムが終了しても何の問題も起こりません。 ＡＮＳＩ-Ｃ準拠の処理系では、プログラムが終了すればすべて解放されるんですね。 「動的メモリ」をmalloc,realloc,callocで確保されたものに限定しても、 この問題については、本によって微妙に異なる説明をしていることがわかりました。 単に「mallocで確保した領域は、プログラムが終了したときには自動的に解放される。」とした本もあります。 別の本にはこう書いてあります。 「mallocしたメモリ領域をfreeすることなく、放置しておくとどうなるでしょう。プログラムが終了する際に、ＯＳはプログラムが使っていたメモリ領域をすべて開放します。そのため、freeを行わなくても、プログラムが終了すれば、自動的に空きメモリになります。といっても、プログラマがfreeを行わなくても良い、ということではありません。mallocによってＯＳから借りたメモリは、必要がなくなった時点でfreeにより、ＯＳに返すのが、Ｃ言語でのルールです。」（『Ｃ言語ポインタが理解できない理由』） ここでいう「Ｃ言語でのルール」というのがＡＮＳＩ－Ｃかどうかわかりません。 また他の本では 「現状で、ＰＣなどで普通に使われているオペレーティングシステムなら、プロセス終了時に、そのプロセスが確保していた領域は、確実に解放してくれます。 もっとも、それは、Ｃの規格で規定されているわけではないのですが、まともなＯＳならまず大丈夫です。」（『Ｃ言語ポインタ完全制覇』） これらの本で言いたいことは、 「現実に世の中で広まって使われているようなＯＳではプログラム終了時に解放しているが、それはＣ言語の規格で決まっていることではないので、Ｃ言語で処理系に依存しないように正しくプログラミングするときには、終了時に解放すべきだ」 ということだろうと思います。 ＡＮＳＩ－Ｃ準拠ならば終了時に解放するといえるのか、と追究したい気持ちもあるんですが、あまり実益がなさそうなので、やめます。
お答えは、No.1, No.2の方の答えのとおりですが、多分リソース不足の意味もご存知ないとのことなのでわかりやすく翻訳しましょう。 1.メモリ、リソースメモリ a)メモリにはデータ領域、プログラム領域として割り当てられるメモリ(mallocwで割り当てられる)と b)主にウィンドウ表示、その他プログラム側より主にＯＳにお願いする仕事をやり取りする特別なメモリ領域であるリソースメモリ がプログラムを組むときに必要になります。 ２．メモリの習得、解放 mallocで割り当てられたメモリは通常アプリケーションでfreeされますが、もししなかった場合でも、そのアプリケーション自体が終了するときにOSが解放します。 例外はNo.2の方が言われたようなOS自身が使っているとか、ほかのプログラムと共有しているメモリの場合などですね。 つまり、通常は問題が起きません。しかし、たとえばほかのアプリケーションから子供のプロセスとして起動するなどの場合は要注意です。 なので、知らない間に問題が発生しているということになります。 ３．リソースメモリ こちらはより厄介です。これは明示的に解放してあげないと、プログラムが終了しても解放してくれません。 たとえば、プログラムでWindowを沢山作って表示して、でもちゃんと解放せずに終了してしまうような作りとか、前のリソースメモリを解放せずにポインタに新しいリソースメモリを割り当ててしまうなどしてしまうと、それがそのまま残ってしまいます。 一般にこのような解放されずに使われないメモリ領域が発生することをメモリリークと呼んでいます。 安定なシステムを構築する場合には深刻な問題になります。 Windows98が長期間安定に動作を続けられないのも、このメモリリークに弱いからです。 Windows2000, XP などはそもそもリソースメモリが豊富にあるので、まだ安定性は高いのですが。 リソースメモリの量はアクセサリの中にリソースメータというプログラムがありますので、それで見ることができます。 リソースメモリが不足した場合は、システム全体が不安定になります。 どうなるのか試したければ、Windows9x, Me で少々重いソフトを次々と立ち上げてみてください。多分メモリリソース不足という警告を見ることができます。
補足
>２．メモリの習得、解放 >mallocで割り当てられたメモリは通常アプリケーションでfreeされますが、もししなかった場合でも、そのアプリケーション自体が終了するときにOSが解放します。 だから、質問のプログラムは問題が起きないわけですね。 >つまり、通常は問題が起きません。しかし、たとえばほかのアプリケーションから子供のプロセスとして起動するなどの場合は要注意です。 >なので、知らない間に問題が発生しているということになります。 本当は、 子供のプロセスとして起動するとはどういうことか、 なぜその場合は「要注意」なのか、 などと突っ込んで考えてみたいところですが、 私の知識では、いろいろ調べたり説明をいただいてもわからないと思いますので、やめておきます。 >３．リソースメモリ >こちらはより厄介です。これは明示的に解放してあげないと、プログラムが終了しても解放してくれません。 なるほど、リソースメモリの場合は、「ＯＳが自動的に解放する」とはならないんですね。 >一般にこのような解放されずに使われないメモリ領域が発生することをメモリリークと呼んでいます。 「メモリリーク」という言葉はふつうそういう意味のようです（本にもそう書いてあります。）が、今手元にある『Ｃ言語ポインタが理解できない理由』（浅井淳 著）という本では微妙に違うニュアンスで説明されています。 「mallocで獲得したメモリ領域が、プログラムのどこからも参照できなくなってしまった状況をメモリ・リークと呼びます。メモリ・リークは、ポインタのハンドリングを誤ると簡単に起こります。」 使い方は違うが、結局は使わないメモリ領域が解放されずに残るんですから同じことなんでしょう。 >リソースメモリの量はアクセサリの中にリソースメータというプログラムがありますので、それで見ることができます。 なかったので、98ＳＥのＣＤ－ＲＯＭで追加しました。
- ranx
- ベストアンサー率24% (357/1463)
UNIXならterra5さんの回答で概ね合っていると思うのですが、 Windowsということなので、恐らくcheさんのおっしゃる通りでしょう。
補足
Ｃ言語ではどうとかというよりも、ＯＳによって違うんですね。
- terra5
- ベストアンサー率34% (574/1662)
mallocした領域が何か,解放しないとどうなるかは、 C言語というよりは、mallocの実現方法(実際のライブラリの中身)と、OSのメモリ管理方法によると思います。 通常は,mallocが使った領域はプロセスが終了した時点で消滅します(解放されます)。 問題があるとすれば、OSそのものが使うメモリの管理であるとか、 単一のプロセスだけで使わず複数のプロセスで使うようなものだろうと思います。 OSとはいってもプログラムの一種ですから、内部的にはmalloc(もしくは相当のこと)を行いますが, OSはシャットダウンまで終了しませんから、 プロセスを追加し、終了した時にメモリをきちんと解放していなければ、 それはOSというプログラムが終了するまで占有されたままになります。 また、ある種のメモリは複数のプロセスで使われるため、一つのプロセスが終了しても他のプロセスが使う、使っている可能性があるため、 簡単には解放できません。 本来なら使っているプロセスが全て終了した時点できれいになくなればいいのですが、 そうならない場合があり、 これも同様に無駄となります。 おそらく、詳しい話をするとなるとOSがどうやってメモリを管理しているかと言うOS内部の話になります。 例えば,あるOSはプロセスが起動すると、用途により何種類かに分類されたメモリを別々に割り当てます. 何故わけるかというと、メモリをより効率よく使うためや、実行を早くするため等です。 ・・・というような話になります。多分。
補足
>mallocした領域が何か,解放しないとどうなるかは、 >C言語というよりは、mallocの実現方法(実際のライブラリの中身)と、OSのメモリ管理方法によると思います。 処理系によって異なるので、一概に言えないということですね。 >通常は,mallocが使った領域はプロセスが終了した時点で消滅します(解放されます)。 正しいプログラムを書くときも、終了直前にfreeする必要はないという意味ですね。 >問題があるとすれば、OSそのものが使うメモリの管理であるとか、 >単一のプロセスだけで使わず複数のプロセスで使うようなものだろうと思います。 質問のソースではfreeしてもしなくても、コンピュータがおかしな動きをすることはないんですね。 >OSはシャットダウンまで終了しませんから、 >プロセスを追加し、終了した時にメモリをきちんと解放していなければ、 >それはOSというプログラムが終了するまで占有されたままになります。 「プロセスを追加する」とは、プロセスを起動させることですね。 プロセスを起動させるときに、そのプロセスが使うための領域をＯＳが確保するんだけど、プロセスが終了したら、ＯＳがちゃんと解放しないとだめだということですね。 （ＯＳ自体はシャットダウンするまで終わらないから、ＯＳが動いている以上、ＯＳの確保した領域は、「終了したから自動的に解放される」とはならないんですね。 >また、ある種のメモリは複数のプロセスで使われるため、一つのプロセスが終了しても他のプロセスが使う、使っている可能性があるため、 >簡単には解放できません。 ひとつのプロセスが終了しても解放されないようにするにはどうすればよいのでしょうか。 いったいそのような領域はいつ解放されるのでしょうか。解放はfree関数で行うのでしょうか。（Ｃ言語の場合） >本来なら使っているプロセスが全て終了した時点できれいになくなればいいのですが、 >そうならない場合があり、 >これも同様に無駄となります。 なぜ「そうならない」のでしょうか。 あまり詳しい説明を求めるとたいへんなことになりますので、できればでいいです。
ＯＳが確保する利用可能なメモリ、リソース領域は 限られているので、使用した後解放を行わないと、いずれ 蓄積され、ＯＳがフリーズします。リソースメータ等で 蓄積状況は確認できます。Ｗｉｎ９８なら、 （特に）ＩＥ等の操作中にフリーズを起こすことが ありますが、ああいった具合になります。 ただ質問のソースでは少なくとも数十ＭＢのリークを 起こさなければ、確認はしていくことはできないと 思われます。 昔、メモリ容量が現在よりずっと小さかったころは、 わずかのメモリ使用にも気を使っていたので、シビアに チェックされてましたが、現在は少々のものは平気です。 しかし、数時間～数百時間稼動するシステムでは、 １個所のリークコーディングが膨大な量のリークに つながるので許されません。 メモリリークとリソースリークについては、前者は アプリ終了時には解放、後者は再起動するもで解放 されない、です。要するに質問のソースでは無限ループ 等で常駐状態でなければ意味がないということ。 でも、Ｃ言語をやるのならば動的メモリの解放は、常識と して必須です。考えずに必ずやります。 ※自動変数はローカルメモリ、動的確保はヒープメモリ で自動変数にはあまり大きいサイズには利用でません。 そういった意味でも malloc を利用します。
補足
私はひとつひとつ丁寧に読むことにしますので、補足またはお礼までするのにお時間をいただきます。 >ＯＳが確保する利用可能なメモリ、リソース領域は >限られているので、使用した後解放を行わないと、いずれ >蓄積され、ＯＳがフリーズします。 まず確認したいのは、ここでおっしゃっていることを言い換えると、 「mallocしてfreeせずにプロセスが終了すると、その領域は他のプロセスで使えないので、ＯＳであっても使うことはできない。 そのようなことを繰り返すと、使えない領域がメモリ上にどんどん増えてしまう。 ＯＳがメモリを使おうとしても必要な領域が確保できないため、ＯＳは活動できなくなり、人がコンピュータに働きかけても、反応しなくなってしまう。」 ということでよろしいでしょうか。 >リソースメータ等で >蓄積状況は確認できます。 リソースメータというのは、どこにありますか？ アクセサリのシステムツールの中に「システム情報」というものがありますが、それでわかりますか？ >ただ質問のソースでは少なくとも数十ＭＢのリークを >起こさなければ、確認はしていくことはできないと >思われます。 質問のソースでも原理的には「解放しないためにコンピュータがおかしくなるプログラム」にはなっているわけですね。ただ、そのときに 100,000,000程度のサイズのmallocを繰り返して行わなければならないわけですね。 （「少なくても」というのですから、これでも十分ではないのかもしれないですね。） >しかし、数時間～数百時間稼動するシステムでは、 >１個所のリークコーディングが膨大な量のリークに >つながるので許されません。 この話はアプリが終了しないで継続して実行するときの話ですよね。 >メモリリークとリソースリークについては、前者は >アプリ終了時には解放、後者は再起動するもで解放 >されない、です。 メモリリークとリソースリークは違うものだとおっしゃっていますね。 質問のソースは、メモリリークであるので、終了時には解放されるんですね。 それでは質問のソースのプログラムを繰り返して何回行おうと、一回一回終了する限り、おかしな動きは起きないわけですね。 ただ、私はリソースリークというものを知らないのです。リソースリークというものはどのようにすれば起きるのでしょうか。 どのようなソースならばそれが起きるのでしょうか。 私には、ご回答の前半と後半とで、質問のソースに関して逆のことを言っているように感じられます。 「質問のソースで、多くのサイズをmallocさせれば、ＯＳがフリーズする」とおっしゃっていますか？ それとも、 「質問のソースでは、たとえどれだけ多くのサイズをmallocしても、ＯＳのフリーズは起きない。」とおっしゃっていますか？
お礼
（補足の後のお礼 ７月13日） 『Ｃ言語 ポインタが理解できない理由』について、出版社に質問したら、答えが返ってきました。 出版社からの答えの文言そのままではないですが、ほぼ次のような内容の答えでした。 「ご質問頂いた項目に関して、以下に回答致しますので、ご査収ください。 （１）freeによりＯＳに返すのか返さないのかという点について、本書では相反する内容が書かれている －－基本的には、アロケートしたメモリはfreeするべきというのが、本書の意見です。freeの動作は正確には、動作環境に基づく内部的な都合により、即座にメモリをＯＳに返しているわけではありません。しかし、以下の（３）にも関係しますが、本書では、アロケートしたメモリを利用終了後に開放する（＝最終的にＯＳ管理下に戻す）という立場ですので、freeするように記述しています。 （２）プログラム終了直前のfreeは必要か？ －－人によっては必要がないという指摘もありますが、本書では（１）、（３）と関係していますが、freeが必要と考えています。 自分でアロケートしたメモリの責任を最後まで考慮するという考えです。 （３）「Ｃ言語でのルール」とは？ －－Ｃ言語でのＡＮＳＩ規格やＫ＆Ｒによる「Programing C」においても「アロケートしたメモリはfreeすることで開放する」となっています。本書もこれらと同じ立場です。 以上 」 （３）で言っているのは、「freeすることで解放するんだ。プログラムが終了することで解放するなんていうことは規格にはないぞ。」ということでしょう。 ということは、この本が言っていることは、 「現実のＯＳでは都合や理由があって、freeしてもすぐにはＯＳに返されるわけではない。またプログラムが終了すれば自動的に解放される。しかし、ルールとしては必ずfreeしなければならない。プログラムが終了する直前であっても解放しなければならない。もし、プログラムが終了しても解放されないような処理系があったとしても規格には反しない。」 ということなんでしょう。「プログラムが終了したら解放されると規格で定まっているが、他方、ルールはルールとしてプログラム終了直前でもfreeしなければならない」という立場では ない ようです。それだったらｔｏｙｓｍｉｔｈさまのＮｏ.６の回答どおり、まったくムダですからね。 本の立場はわかりましたし、プログラムが終了する直前にfreeする必要はない、という立場もわかりました。 どちらが正しいかの判断は私にはできません。 新たなご回答がなければ、数日で締め切りたいと思います。 私としては、ｔｏｙｓｍｉｔｈさまのＮｏ.６が一番わかりやすくて、良かったと思います。 ＞ANSI-Cと一口に言ってもHosted EnvironmentとFree Standig Environmentでは全く違った構成になります。 私は「規格」とかＡＮＳＩ－Ｃと何度も書きますが、よく考えるとそれらの中身をわかっていないようです。よく勉強したいと思います。
補足
ご回答ありがとうございます。 ご回答で問題になっている本『C言語ポインタが理解できない理由』（浅井淳 著、技術評論社）の記述を読み進めていくと、「freeすると本当にメモリはOSに返されるのか？」という節があり、次のようなことが書いてあります。 ----------------------------------- mallocにより取得されるアドレスは、データセグメント内のヒープと呼ばれる領域にある。ヒープは、mallocするたびにスタックの方向に拡張されていく。しかし、freeを行なってメモリを解放しても、ヒープ全体が縮小するわけではない。 では、なぜfreeを行う必要があるのだろうか。freeすることで、ヒープが拡張するのを食い止める働きがある。mallocの内部では、freeされて未使用となった領域があるのなら、その領域を返す。つまりメモリのリサイクルを行う。つまり、free直後は空きメモリになるが、ＯＳには返されず、しばらくはそのままヒープ上に残っている。 ----------------------------------- 私としては最後の「しばらくは」というのも気になりますがそれはともかくとして、どうも著者は、「freeしたからといってメモリはＯＳは返されませんよ。」ということを言っているんだと思います。これはｔｏｙｓｍｉｔｈさまのご回答と符合するので、正しいんだと思います。 しかし、回答No.5の補足で書いたとおり、この本では少し前の方で 「freeを行わなくても、プログラムが終了すれば、自動的に空きメモリになります。といっても、プログラマがfreeを行わなくても良い、ということではありません。mallocによってＯＳから借りたメモリは、必要がなくなった時点でfreeにより、ＯＳに返すのが、Ｃ言語でのルールです。」 と書いてあります。 著者は、自分自身が書いた、この「freeによりＯＳに返す」という記述を否定しているのです。 そうすると、疑問になってくるのは、著者は、本当は「プログラムが終了する直前にはfreeする必要はない」と思っているのではないだろうか、ということです。それとも著者は、「freeしてもＯＳに返されないが、ルールはルールとして守らなければいけない。だから、終了直前でもfreeしなければならない」という意見だろうか、とも考えられます。 （ご回答より） ＞・「C言語のルール」が意味不明 そうですね。 「C言語でのルール」が何かという点も含めて、この本のfreeの記述については、疑問が湧いてきます。 もうあんまり気にしないようにしようかとも思いました。 しかし、この本の最後に、本の内容に関して質問を受け付ける旨が書いてあるので、せっかくなので出版社に質問してみよう、と思いました。