アカウント名:
パスワード:
解放したら、そのポインタにNULLを入れてif (foo){ free(foo); foo = NULL;}
free(NULL);は何もしないことになってるので、if(foo)は無くてもよかったはず。
いかにも経験主義者のいいそうなことですねえ。処理系依存ということをしらないで、単一の環境での動作を絶対視する。組み込み上がりのプログラマに多い気がする。
組み込みなんて、その時々でターゲットもコンパイラも普通に変わるんだが……#ずっと同環境ならどれだけ楽か、なのでAC
# あれ、書いたつもりなんだけど消えちゃった
valgrindなりelectricfenceなり使えば、現象自体はつかまえられます。ただし、テストの自動化が(仮にできたとしても)大変な上に、どうしても漏れが残りますよね。
# そして、stackを踏み越えてハマる、と。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生unstable -- あるハッカー
二重解放 (スコア:1)
最近は安全な文字列操作関数ライブラリ使ったり、コンパイル時に書式文字列と引数の不整合を指摘してくれるコンパイラ使うとか手段があるので、タレコミ後半の通りCそのものの問題ということでもないだろうけど。
CVEの脆弱性リスト眺めてると、二重解放の脆弱性が頻度も多い割りに中々気づけない気がする。何か良い対処方法はありますか?
Re: (スコア:0)
解放したら、そのポインタにNULLを入れて
if (foo){
free(foo);
foo = NULL;
}
Re:二重解放 (スコア:1)
そう拡張すると、#1845563さんの指摘のように、解放済みポインタの不正な参照という問題が出てきますね。
Re:二重解放 (スコア:1)
free(NULL);は何もしないことになってるので、if(foo)は無くてもよかったはず。
1を聞いて0を知れ!
Re:二重解放 (スコア:1, 興味深い)
言語仕様しか知らない頭でっかちの屁理屈だって言われて。
たぶん昔、free(NULL)するとオカシナことになる処理系があったのでしょう。
Re: (スコア:0)
NULLチェックしてNULLだった場合の適切な処理は「何もしない」ではなく「エラーを出す」こと。
値がNULLのポインタをfree()すること自体は問題ないが、
そのような呼び出しフローになるようなプログラムには問題がある。
Re: (スコア:0)
Re: (スコア:0)
Re: (スコア:0)
いかにも経験主義者のいいそうなことですねえ。
処理系依存ということをしらないで、単一の環境での動作を絶対視する。
組み込み上がりのプログラマに多い気がする。
Re: (スコア:0)
組み込みなんて、その時々でターゲットもコンパイラも普通に変わるんだが……
#ずっと同環境ならどれだけ楽か、なのでAC
Re: (スコア:0)
処理系依存とか言うのなら、その処理系が仕様からはずれてるってことじゃないのか?
(組込だとありなのかしら?)
Re: (スコア:0)
if (foo){
free(foo);
foo = NULL;
}
gets(boo);
Re: (スコア:0)
# あれ、書いたつもりなんだけど消えちゃった
valgrindなりelectricfenceなり使えば、現象自体はつかまえられます。
ただし、テストの自動化が(仮にできたとしても)大変な上に、どうしても漏れが残りますよね。
# そして、stackを踏み越えてハマる、と。
Re: (スコア:0)