私の会社では、メモリを解放した後、変数をにリセットするというコーディングルールがありますNULL。例えば ...
void some_func ()
{
int *nPtr;
nPtr = malloc (100);
free (nPtr);
nPtr = NULL;
return;
}上記のコードのような場合、に設定しNULLても意味がないと思います。それとも何か不足していますか？
そのような場合に意味がない場合は、このコーディングルールを削除するために「品質チーム」に取り上げます。アドバイスをお願いします。
回答:
未使用のポインタをNULLに設定することは防御的なスタイルであり、ぶら下がりポインタのバグから保護します。ダングリングポインターが解放された後でアクセスされた場合、ランダムメモリを読み取りまたは上書きする可能性があります。nullポインタにアクセスすると、ほとんどのシステムですぐにクラッシュし、エラーの内容がすぐにわかります。
ローカル変数の場合、解放後にポインターがアクセスされなくなったことが「明白」である場合は、少し無意味になる可能性があるため、このスタイルはメンバーデータおよびグローバル変数に適しています。ローカル変数の場合でも、メモリが解放された後も関数が継続する場合は、良い方法かもしれません。
スタイルを完成させるには、真のポインター値が割り当てられる前に、ポインターをNULLに初期化する必要もあります。
int *nPtr=NULL;。さて、次の行でmallocが続くので、これは冗長であることに同意します。ただし、宣言と最初の初期化の間にコードがある場合、まだ値がないにもかかわらず、誰かが変数の使用を開始する可能性があります。nullで初期化すると、segfaultが発生します。せずに、ランダムメモリを再度読み書きする可能性があります。同様に、後で変数が条件付きでのみ初期化される場合、null初期化を覚えていれば、後で誤ってアクセスするとすぐにクラッシュします。
NULL後へのポインタの設定freeことは疑わしい慣行であり、特許を誤った前提で「適切なプログラミング」ルールとして一般化することがよくあります。これは、「正しいサウンド」のカテゴリに属する偽の真実の1つですが、実際には、まったく何も役に立たない（場合によっては、否定的な結果につながる）こともあります。
伝えられるところNULLによるfreeと、ポインターをafter に設定することで、同じポインター値がfree複数回渡された場合の恐ろしい「二重解放」の問題を防ぐことができます。ただし、実際には、10のうち9つのケースで、同じポインタ値を保持するさまざまなポインタオブジェクトがの引数として使用されると、実際の「二重解放」の問題が発生しfreeます。言うまでもなく、ポインタをNULLafterに設定しても、freeそのような場合の問題を防ぐための絶対的な効果はありません。
もちろん、同じポインタオブジェクトをへの引数として使用すると、「二重解放」問題が発生する可能性がありますfree。ただし、実際の状況では、このような状況は通常、単なる偶発的な「二重解放」ではなく、コードの一般的な論理構造に問題があることを示しています。このような場合の問題に対処する適切な方法は、同じポインターがfree複数回渡される状況を回避するために、コードの構造を見直して再考することです。このような場合、ポインタをNULL「修正済み」の問題を検討することは、カーペットの下で問題を一掃しようとすることに他なりません。コード構造の問題は常にそれ自体を明らかにする別の方法を見つけるので、それは単に一般的なケースでは機能しません。
最後に、コードがポインター値のNULL有無に依存するように特別に設計されている場合はNULL、ポインター値をNULLafter に設定しても問題ありませんfree。しかし、一般的な「良い習慣」のルールとして（「常にNULL後へのポインターを設定するfree」のように）、これもまた、よく知られており、かなり役に立たない偽物であり、純粋に宗教的で、ブードゥー教のような理由で続くことがよくあります。
foo* bar=getFoo(); /*more_code*/ free(bar); /*more_code*/ return bar != NULL;。ここでは、設定barをNULL呼び出した後、free関数は、それが思うようになります決してバーがありませんでしたし、間違った値を返します！
ほとんどの応答は二重解放の防止に重点を置いていますが、ポインターをNULLに設定すると別の利点があります。ポインタを解放すると、そのメモリは、mallocへの別の呼び出しで再割り当てできるようになります。元のポインターがまだ残っている場合、解放後にポインターを使用しようとすると他の変数が破損するというバグが発生し、プログラムが不明な状態になり、あらゆる種類の悪いことが発生する可能性があります（運が良ければ、運が悪ければデータが破損します）。解放後にポインタをNULLに設定した場合、後でそのポインタを介して読み取り/書き込みを試みると、segfaultが発生します。これは、ランダムメモリの破損よりも一般的に望ましい方法です。
どちらの理由でも、free（）の後でポインターをNULLに設定することをお勧めします。ただし、常に必要というわけではありません。たとえば、ポインタ変数がfree（）の直後にスコープ外になった場合、それをNULLに設定する理由はあまりありません。
freeが、これは実際に理にかなっています。
これは、メモリの上書きを回避するための良い方法と考えられています。上記の関数では不要ですが、実行するとアプリケーションエラーが見つかる場合があります。
代わりに次のようなものを試してください：
#if DEBUG_VERSION
void myfree(void **ptr)
{
free(*ptr);
*ptr = NULL;
}
#else
#define myfree(p) do { void ** __p = (p); free(*(__p)); *(__p) = NULL; } while (0)
#endifDEBUG_VERSIONを使用すると、コードのデバッグで空きをプロファイルできますが、どちらも機能的には同じです。
編集：以下に提案するように、do ...を追加しました。ありがとうございます。
do { } while(0)ようにブロックで囲む必要がありますif(x) myfree(x); else dostuff();。
do {X} while (0)はIMOであり、関数のように感じ、機能するマクロボディを作成する最良の方法です。ほとんどのコンパイラはとにかくループを最適化します。
free（）dされているポインタに到達すると、壊れるかどうかがわかります。そのメモリはプログラムの別の部分に再割り当てされる可能性があり、メモリが破損します。
ポインタをNULLに設定した場合、それにアクセスすると、プログラムは常にsegfaultでクラッシュします。予測できない方法でクラッシュすることはありません。デバッグがはるかに簡単です。
ポインターをfree'dメモリーに設定すると、ポインターを介してそのメモリーにアクセスしようとすると、未定義の動作が発生する代わりに、すぐにクラッシュします。これにより、問題が発生した場所を簡単に特定できます。
私はあなたの議論を見ることができます：nPtrはの直後に範囲外nPtr = NULLになるので、に設定する理由はないようですNULL。ただし、structメンバーの場合や、ポインターがすぐにスコープ外にならない場所では、より理にかなっています。そのポインタが、それを使用してはならないコードによって再び使用されるかどうかはすぐにはわかりません。
ルールがこれら2つのケースを区別せずに記述されている可能性があります。ルールを自動的に適用することはもちろんのこと、開発者がルールを実行することはさらに難しいためです。NULLすべての解放後にポインタを設定しても問題はありませんが、大きな問題を指摘する可能性があります。
cの最も一般的なバグは、二重解放です。基本的にあなたはそのようなことをします
free(foobar);
/* lot of code */
free(foobar);そしてそれは結局かなり悪いことになります、OSはすでに解放されたメモリを解放しようとし、一般的にそれはsegfaultです。したがって、に設定するNULLことをお勧めします。テストを行い、このメモリを本当に解放する必要があるかどうかを確認できます。
if(foobar != null){
free(foobar);
}また、free(NULL)何も実行しないので、ifステートメントを記述する必要はありません。私は実際にはOSの第一人者ではありませんが、今でもほとんどのOSは二重解放でクラッシュします。
これは、ガベージコレクションを使用するすべての言語（Java、dotnet）がこの問題を抱えておらず、メモリ管理全体を開発者に任せる必要がないことを誇りに思っている主な理由でもあります。
p = (char *)malloc(.....); free(p); if(p!=null) //p!=null is true, p is not null although freed { free(p); //Note: checking doesnot prevent error here }
free(void *ptr) ことはできません。これは変更することができるコンテンツポインタの、そのアドレスに格納されたデータではなく、アドレス自体、またはポインタの値。それにはfree(void **ptr)（明らかに標準では許可されていない）またはマクロ（許可されており、完全に移植可能ですが、マクロは好きではありません）が必要です。また、Cは利便性ではなく、プログラマが望むだけの制御をプログラマに与えることです。ポインタをに設定するオーバーヘッドの増加を望まない場合はNULL、強制するべきではありません。
free」（「メモリ割り当て関数の結果をキャストする」、「型名を「で考え抜いて使うsizeof」など）も含まれます。
これは（実際に）重要です。あなたはメモリを解放しますが、プログラムの後の部分は、たまたまスペースに着陸する新しい何かを割り当てることができます。これで、古いポインタは有効なメモリのチャンクを指すようになります。その後、誰かがポインタを使用して、プログラムの状態が無効になる可能性があります。
ポインタをNULLにすると、それを使用しようとすると、0x0が逆参照されてすぐにクラッシュし、デバッグが容易になります。ランダムメモリを指すランダムポインターはデバッグが困難です。それは明らかに必要ではありませんが、それがベストプラクティスドキュメントにある理由です。
ANSI C標準から：
void free(void *ptr);free関数は、ptrが指すスペースの割り当てを解除します。つまり、追加の割り当てに使用できるようになります。ptrがNULLポインターの場合、アクションは発生しません。それ以外の場合、引数がcalloc、malloc、またはrealloc関数によって以前に返されたポインターと一致しない場合、または領域がfreeまたはreallocの呼び出しによって割り当て解除された場合の動作は未定義です。
「未定義の動作」は、ほとんどの場合プログラムのクラッシュです。これを回避するために、ポインタをNULLにリセットしても安全です。free（）自体は、ポインターへのポインターではなくポインターのみが渡されるため、これを行うことはできません。ポインタをNULLにするfree（）のより安全なバージョンを作成することもできます。
void safe_free(void** ptr)
{
free(*ptr);
*ptr = NULL;
}NULLマスキングエラーを回避するために設定する必要がある理由を見つけました。stackoverflow.com/questions/1025589/…どちらの場合も、いくつかのエラーが非表示になるようです。
私の経験では、解放されたメモリ割り当てにアクセスするとき、ほとんどの場合、これはほとんど役に立ちません。どこかへの別のポインタがあるためです。そして、それは「無駄な混乱を避ける」である別の個人的なコーディング標準と衝突するので、コードを少しだけ読みにくくするのに役立つことはめったにないと思うので、私はそれをしません。
ただし、ポインタが再度使用されることになっていない場合は、変数をnullに設定しませんが、多くの場合、より高いレベルの設計により、とにかくnullに設定する理由が得られます。たとえば、ポインターがクラスのメンバーであり、それが指すものを削除した場合、そのクラスの「契約」は、そのメンバーがいつでも有効なものを指すため、nullに設定する必要があるということです。そのため。小さな違いですが、重要なものだと思います。
C ++では、誰が所有するかを常に考えることが重要ですメモリを割り当てるときこのデータのです（スマートポインターを使用している場合を除いて、いくつかのが必要です）。そして、このプロセスは一般的にポインタがいくつかのクラスのメンバーになる傾向があり、一般的にはクラスを常に有効な状態にしたいので、メンバー変数をNULLに設定してポイントすることを示すのが最も簡単な方法です。今は何にも。
一般的なパターンは、コンストラクターですべてのメンバーポインターをNULLに設定し、デストラクタが、クラスが所有していると設計が示すデータへのポインターに対して削除を呼び出すことです。明らかにこの場合、何かを削除するときにポインターをNULLに設定して、以前にデータを所有していないことを示す必要があります。
要約すると、はい、私はしばしば何かを削除した後にポインタをNULLに設定しますが、それは大規模な設計の一部としてであり、コーディング標準ルールに盲目的に従うためではなく、データを所有する人についての考えです。私はあなたの例ではそうしません。そうすることには利点がなく、私の経験では、この種のものと同じくらいバグと悪いコードの原因である「乱雑」を追加するからです。
このルールは、次のシナリオを回避しようとする場合に役立ちます。
1）複雑なロジックとメモリ管理を備えた本当に長い関数があり、削除されたメモリへのポインタを後で関数で誤って再利用したくない場合。
2）ポインターは、かなり複雑な動作をするクラスのメンバー変数であり、他の関数で削除されたメモリへのポインターを誤って再利用したくない場合。
あなたのシナリオでは、それはあまり意味がありませんが、関数が長くなると、それが問題になる場合があります。
これをNULLに設定すると、実際には後で論理エラーがマスクされる可能性があると主張するかもしれません。
一般的に、それが良いアイデアだと思うときはNULLに設定し、価値がないと思うときは気にしないことをお勧めします。代わりに、短い関数と適切に設計されたクラスを書くことに焦点を当ててください。
他の人が言ったことに加えて、ポインターの使用法の1つの良い方法は、それが有効なポインターであるかどうかを常にチェックすることです。何かのようなもの：
if(ptr)
ptr->CallSomeMethod();
ポインターを解放した後で明示的にNULLとしてマークすると、C / C ++でこの種の使用が可能になります。
これはすべてのポインタをNULLに初期化するためのより多くの引数かもしれませんが、このようなものは非常に卑劣なバグになる可能性があります：
void other_func() {
int *p; // forgot to initialize
// some unrelated mallocs and stuff
// ...
if (p) {
*p = 1; // hm...
}
}
void caller() {
some_func();
other_func();
}pスタック上の前者と同じ場所に配置されるnPtrため、有効なポインタが含まれている可能性があります。に割り当てると*p、関係のないあらゆる種類のものが上書きされ、醜いバグにつながる可能性があります。特に、コンパイラがデバッグモードでローカル変数をゼロで初期化したが、最適化をオンにしていない場合。したがって、デバッグビルドはバグの兆候を示さず、リリースビルドはランダムに爆発します...
解放されたばかりのポインタをNULLに設定することは必須ではありませんが、良い方法です。このようにして、1）解放された先の尖った2）を2回解放することを回避できます。
NULLへのポインターの設定は、いわゆるダブルフリーを再度保護することです。そのアドレスでブロックを再割り当てせずに、同じアドレスに対してfree（）が複数回呼び出される状況です。
ダブルフリーは未定義の動作につながります-通常、ヒープの破損またはプログラムの即時クラッシュ。NULLポインタに対してfree（）を呼び出しても何も行われないため、安全であることが保証されています。
したがって、free（）の直後または直後にポインターがスコープを離れることが確実でない限り、free（）が再度呼び出されてもNULLポインターと未定義の動作が呼び出されるように、ベストプラクティスはそのポインターをNULLに設定することです。回避されます。
元の質問へ：内容を解放した直後にポインタをNULLに設定することは、コードがすべての要件を満たし、完全にデバッグされ、再度変更されることがなければ、時間の無駄です。一方、解放されたポインターを防御的にNULLにすることは、誰かがfree（）の下に新しいコードブロックを不注意に追加した場合、元のモジュールの設計が正しくない場合、およびその場合に非常に役立ちます。 -compiles-but-doesn't-do-what-I-wantバグ。
どのシステムでも、正しいことを最も簡単にするという達成不可能な目標があり、不正確な測定の削減できないコストがあります。Cでは、熟練労働者の手に多くのことを生み出し、不適切に取り扱われるとあらゆる種類の隠喩的な損傷を与える可能性のある、非常に鋭い、非常に強力なツールのセットを提供しています。一部は正しく理解または使用するのが難しいです。そして、人々は自然にリスクを嫌うので、ポインタをNULL値でチェックしてからそれを使ってfreeを呼び出すなど、不合理なことをしています…
測定の問題は、良いものと悪いものを分けようとするときはいつでも、ケースが複雑になるほど、あいまいな測定値が得られる可能性が高くなることです。目標が良い実践のみを維持することである場合、いくつかのあいまいなものは、実際には良くないものを捨てられます。目標が善ではないものを排除することである場合、あいまいさは善にとどまることがあります。良好な状態を維持するか、明らかに悪い状態を排除するという2つの目標は正反対ですが、通常、3つ目のグループはどちらか一方ではなく、両方とも存在します。
品質部門に報告する前に、バグデータベースを調べて、無効なポインター値が原因で書き留めなければならない問題が発生した頻度を確認してください。実際の違いを作りたい場合は、本番コードで最も一般的な問題を特定し、それを防ぐ3つの方法を提案します
2つの理由があります。
cの最も一般的なバグは、二重解放です。基本的にあなたはそのようなことをします
free(foobar); /* lot of code */ free(foobar);そしてそれは結局かなり悪いことになります、OSはすでに解放されたメモリを解放しようとし、一般的にそれはsegfaultです。したがって、に設定する
NULLことをお勧めします。テストを行い、このメモリを本当に解放する必要があるかどうかを確認できます。if(foobar != NULL){ free(foobar); }また、
free(NULL)何も実行しないので、ifステートメントを記述する必要はありません。私は実際にはOSの第一人者ではありませんが、今でもほとんどのOSは二重解放でクラッシュします。これは、ガベージコレクションを使用するすべての言語（Java、dotnet）でこの問題がなく、メモリ管理全体を開発者に任せる必要がないことを誇りに思っている主な理由でもあります。
書かれたマーティン・V。LOWISで別の答え。
未使用のポインタをNULLに設定することは防御的なスタイルであり、ぶら下がりポインタのバグから保護します。ダングリングポインターが解放された後でアクセスされた場合、ランダムメモリを読み取りまたは上書きする可能性があります。nullポインターにアクセスすると、ほとんどのシステムですぐにクラッシュし、エラーの内容がすぐにわかります。
ローカル変数の場合、解放後にポインターがアクセスされなくなったことが「明白」である場合は、少し無意味になる可能性があるため、このスタイルはメンバーデータおよびグローバル変数に適しています。ローカル変数の場合でも、メモリが解放された後も関数が継続する場合は、良い方法かもしれません。
スタイルを完成させるには、真のポインター値が割り当てられる前に、ポインターをNULLに初期化する必要もあります。
次のように、ポインタ変数をNULLで宣言することを常にお勧めします。
int *ptr = NULL;たとえば、ptrが0x1000のメモリアドレスを指しているとします。を使用した後はfree(ptr)、再度NULLに宣言してポインタ変数を無効にすることをお勧めします。例えば：
free(ptr);
ptr = NULL;NULLに再宣言されていない場合でも、ポインター変数は同じアドレス（0x1000）をポイントし続けます。このポインター変数は、ダングリングポインターと呼ばれます。別のポインター変数（たとえば、q）を定義し、新しいポインターに動的にアドレスを割り当てる場合、同じアドレス（新しいポインター変数によって 0x1000）ます。場合には、あなたが同じポインタ（使用している場合はPTRを）と同じポインタ（が指すアドレスに値を更新PTR）、プログラムは場所に値を書き込むことになりますqがあるため（指しているのpとqはあります同じアドレス（0x1000を））。
例えば
*ptr = 20; //Points to 0x1000
free(ptr);
int *q = (int *)malloc(sizeof(int) * 2); //Points to 0x1000
*ptr = 30; //Since ptr and q are pointing to the same address, so the value of the address to which q is pointing would also change.簡単に言うと、解放したアドレスに誤って（誤って）アクセスしたくありません。アドレスを解放すると、ヒープ内のそのアドレスを他のアプリケーションに割り当てることができるからです。
ただし、ポインターをNULLに設定せず、誤ってポインターの逆参照を試みるか、そのアドレスの値を変更してください。あなたはまだそれを行うことができます。ただし、論理的に実行する必要があるものではありません。
解放したメモリ位置にまだアクセスできるのはなぜですか？理由：メモリを解放している可能性がありますが、ポインタ変数にはヒープメモリアドレスに関する情報が残っています。したがって、防御戦略として、NULLに設定してください。
ptr == NULL使って何かをする前に、それが何かをチェックできることは常に役に立ちます。解放されたポインタを無効にしないと、取得ptr != NULLできますが、まだ使用できないポインタです。