mallocの後にfree不要と言うバカいるの?Part2

■ このスレッドは過去ログ倉庫に格納されています
2013/01/30(水) 21:38:37.44
fjの時代から10年以上に渡るmalloc/free問題について語ってください(^q^)

前スレ
main以外★mallocの後にfree不要と言うバカいるの?
http://toro.2ch.net/test/read.cgi/tech/1352812333/
2013/01/30(水) 21:42:04.63
ここまでのまとめ
・freeいる派完全勝利
・freeいらない派のくさおが発狂、レスを流すのに必死
・freeいらない派のくさおがバグ付スタックオーバフローソースを作成、
　身をもってfreeは危険だと主張
・freeいらない派のくさおが自演を開始、自画自賛を始める
・freeいらない派のくさおが自演を指摘され遁走　←いまここ
2013/01/30(水) 21:42:28.73
前スレ1


1 名前：デフォルトの名無しさん[sage] 投稿日：2012/11/13(火) 22:12:13.29
前提１：一般的なC言語（GC搭載していない）
前提２：main関数は除く
前提３：関数実行後すぐに終了するとは限らない
前提４：関数は何度も使われることがある


これがメモリリークするのは当たり前の話で、
mallocをしたらfreeするのは当たり前。

free不要論とは一体何だったのか。

天邪鬼（バカ）が言葉尻を捉えていただけではないだろうか。
まつもと ゆきひろもそのバカの一人だったらしいね。

例外中の例外を除いて、mallocをしたらfreeは必要。
これが真の答えだろう。
2013/01/30(水) 21:44:23.19
freeいる派の主な主張
・mtraceが通らないとか論外
・対にするようにしておかないと悪癖が身に付く
・そもそも最後にまとめて解放すること自体が論外

freeいらない派の主な主張
・freeでバグる可能性があるから解放したくない
・プロセスの終了処理に黙って解放されるほうが終了処理がはやい
2013/01/30(水) 22:06:09.81
なんかスレ立てたら賢者モードになっちゃったよ。
前スレで議論してたのがうそみたい。


ところで、Perl、Python、RubyなんかのP言語が猛威をふるい
Javaなんかもガベコレ積んでるし、
Windowsアプリの主要開発言語もC#になろうかとしている今、

今後、手動でメモリ確保、メモリ解放しなきゃならない環境ってのは
どういうのが残るかなぁ

AppleのObjective-C、組み込み開発、ドライバ、OS等のハードに直結した部分
数値計算とかそういう純粋に速度が要求される分野

思いついたのはこのくらいなんだけど
他にないかなぁ
2013/01/30(水) 22:15:43.17
Objective-Cは最近は手動じゃないっぺ。
2013/01/30(水) 23:29:05.06
このスレッドは天才チンパンジー「アイちゃん」が
言語訓練のために立てたものです。

アイと研究員とのやり取りに利用するスレッドなので、
関係者以外は書きこまないで下さい。

　　　　　　　　　　　　　　　　　　京都大学霊長類研究所
8デフォルトの名無しさん
垢版 |
2013/01/31(木) 06:30:05.64
freeする前に終了しちゃえばいいさ
2013/01/31(木) 07:58:46.76
「main 以外」なんだからねっ！
不毛な議論しちゃダメ、絶対。

ところで、exit 適用時も議論対象外に、入りますか？
2013/01/31(木) 10:16:50.76
「main以外」抜いたここは別スレだろ
11デフォルトの名無しさん
垢版 |
2013/02/01(金) 03:11:22.90
こっちが本スレで向こうが隔離スレでしょ
この議論はUNIXの"悪習"が元凶のような気がしてきた
2013/02/01(金) 21:24:43.72
ぶっちゃけ2000年問題と同レべの手抜き習慣
2013/02/01(金) 23:42:42.74
俺もOS評価するときにOS再インスコが
必要になったらPCの電源をブチっと
落とすけど、そんな感じ？
2013/02/02(土) 09:39:47.82
使い捨てのプログラムで、コンパイラみたいな一度走って終わりのプログラムなら、
全部mallocしっぱなし、ってこともある。時と場合による。
2013/02/02(土) 10:41:02.65
"main以外"を抜いて、また１からやり直したいのか？>>1は
2013/02/02(土) 10:42:00.23
>>13
どっちかというと、再インストール関係なしに「もうディスクにアクセスする必要が
ないことがわかっているから」といってrebootのかわりにリセット押すのが近いだろう。
2013/02/02(土) 23:13:35.87
スレチだが、
sprintf(buf,…);
len=strlen(buf);
という低脳なコードを久しぶりに見たw
2013/02/02(土) 23:27:39.79
946 ：デフォルトの名無しさん：2013/01/29(火) 22:41:57.29
そもそも最後にまとめて解放すればいいという設計がおかしいんだよ。
最後にまとめて解放するくらいならプロセスの終了に任せれば、って
話になるのはそのため。

mtraceの話も出てるけど、リストだろうがツリーだろうが、使っていると
認識している箇所だけを正しく解放していって、最後に何が残るかを
見ないとリークしてるかどうかなんてわからないだろ。

最後にツリーまとめて消してみたら全部消えたのでリークしてません、
なんてことにはならないんだから。
そこに解放したつもりになっているデータが連結されているかどうか
というのが重要なのに。

947 ：デフォルトの名無しさん：2013/01/29(火) 22:45:04.83
こりゃまた大きな釣り針だな。ｗｗｗ

948 ：デフォルトの名無しさん：2013/01/29(火) 22:47:30.66
くさお悔しくて絶好調だな

949 ：デフォルトの名無しさん：2013/01/29(火) 22:47:59.75
>>946
まとめて消して消えるならリークしてないだろ。バカか。
2013/02/03(日) 00:20:47.51
>>17
それやったことあります。汚物見せてごめんなさい。
2013/02/03(日) 06:27:33.11
>>17
そういうコードが必要な場合もある。
どういう場合かは、あんたには分からんだろうがね。
2013/02/03(日) 06:33:39.57
100%ありません
2013/02/03(日) 06:45:51.40
>>21
1行目と2行目でbufの内容が変わることは100%あり得ない

と思ってんだろ？素人君
2013/02/03(日) 07:38:05.86
>>22
はい。100%あり得ません。
bufが共有であるならセマフォなり何らかの排他をしないのは単なるバグです。
2013/02/03(日) 08:04:22.63
>>17
俺も数えるのめんどくさくてやってしまいそうだが。正解は？
2013/02/03(日) 08:20:18.25
>>23
あれを見た瞬間にその「単なるバグ」の可能性にまで気づくかどうかの問題
後出しでは意味なし
2013/02/03(日) 08:34:17.19
>>25
>そういうコードが必要な場合もある。

じゃあ後出しでない回答を期待します。
逃げたければ逃げてもいいですよ。
2013/02/03(日) 08:38:32.01
>>26
もう答えはでている
あんたが理解できていないだけだ
2013/02/03(日) 08:39:16.13
>>24
len = sprintf(buf,…);
2013/02/03(日) 08:47:16.68
「低脳」
草生やし
卑屈で低レベルな煽り

…まともに相手する必要を認めず。
2013/02/03(日) 08:49:45.14
>>29
敗北宣言ありがとうございますｗ
2013/02/03(日) 08:52:06.97
議論を勝ち負けで考えているかぎり
お前らの勝ちは一生ありえないよ。
2013/02/03(日) 09:47:06.42
>>22
そもそも2行目が不要なことを理解できない低脳君乙。
33デフォルトの名無しさん
垢版 |
2013/02/03(日) 10:01:05.79
> スレチだが、と言って、脈絡もなく>>17を投下したのはこのスレの
異常に高いバカ召喚性能を使いたかったからだろ。ｗｗｗｗ
釣られたバカが>>22 ｗｗｗｗ
2013/02/03(日) 10:16:26.71
いつもの草男がだんだん本性を現してきました
35デフォルトの名無しさん
垢版 |
2013/02/03(日) 10:36:32.83
つられたバカが悔しがってるな。 ｗｗｗｗ
なんでバカって簡単につられるんだろう。 あっ、バカだからか。ｗｗｗｗ
2013/02/03(日) 10:42:10.53
>>22がバカだからくさおだろう
37デフォルトの名無しさん
垢版 |
2013/02/03(日) 10:55:25.21
>>22が書きそうなコード
if(p!=NULL)free(p);
3819
垢版 |
2013/02/03(日) 11:20:12.04
>>37
> if(p!=NULL)free(p);

それも、いま知るまでやっていました…
2013/02/03(日) 11:41:14.21
>>38
基地外スレであんまり真面目ぶると、逆に工作員認定される
40デフォルトの名無しさん
垢版 |
2013/02/03(日) 11:51:22.60
sprintfは使用禁止。バカしか使わない。ｗｗｗｗ
釣られた>>22 バカすぎ ｗｗｗｗ

> From: [22] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 06:45:51.40
>
> >>21
> 1行目と2行目でbufの内容が変わることは100%あり得ない
>
> と思ってんだろ？素人君
41デフォルトの名無しさん
垢版 |
2013/02/03(日) 12:03:02.08
↑くさお書き込みテンプレ
42デフォルトの名無しさん
垢版 |
2013/02/03(日) 12:04:11.64
>>38
freeにNULLを与えた時の動作が標準化されたのはC89からだったはずだから、
20年くらい前のソースならそのように書かれていても不思議じゃない。

作ったライブラリが予想もしない所で使われるかもしれないから、
freeしろとかほざいているfreeバカは、NULL与えるとSEGVする環境(SystemV)に
持って行かれるかもしれないからチェックしろとか言わないのか? ｗｗｗｗ
2013/02/03(日) 12:23:57.18
終了時にメモリ解放してくれるのはどのC言語の規格書に書いてるの？
2013/02/03(日) 12:24:37.29
＞freeにNULLを与えた時の動作が標準化されたのはC89からだったはずだから、
馬鹿死ね
K&R1 からだ

realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話であればこれは有名
2013/02/03(日) 12:42:04.81
>>37
コンパイラが最適化してくれるので問題ありません。
2013/02/03(日) 13:37:59.35
>>45
しない
コンパイラからはfree() は単なる一つの関数にしかみえない
p が 0 のとき free(p) はなにもしないことは、コンパイラはしらない
勉強不足だ、これではwww野郎やQZすらの相手にもならない

死ね
2013/02/03(日) 13:42:43.89
>>46
素人乙
2013/02/03(日) 13:46:41.46
>>46
コンパイラがライブラリの仕様を把握していないと矛盾が生じます。
printfが書式文字列に従って値を表示することをしらなければ出せない
はずの、書式文字列と引数があっていないときのwarningを出せます。
同じように、if(!p)free(p)という悪しき慣例があることも知っています。
2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

できないのなら市ね
2013/02/03(日) 13:48:21.26
>>48
＞書式文字列と引数があっていないときのwarningを出せます。
ほう、それはgccだねこれは一本とられた。よく頑張ったね。
2013/02/03(日) 13:50:06.53
>>49
なんでfreeのほうを省くの？バカなの？死ぬの？
2013/02/03(日) 13:51:19.74
>>50
×それはgccだね
○俺はgccしか知らない
53デフォルトの名無しさん
垢版 |
2013/02/03(日) 13:53:28.26
本日の大バカ晒しage


49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ

49 ：デフォルトの名無しさん：2013/02/03(日) 13:47:08.31
>>47
ではfree(0)を省いてくれる処理系を挙げてみよ
54デフォルトの名無しさん
垢版 |
2013/02/03(日) 13:59:20.99
>>51
const char *p = NULL;
free(p);

だったら最適化でfree(p)を消してくれるかもねｗ
2013/02/03(日) 14:03:19.10
逆に、mallocがNULLを返したかチェックしない人多いよね。
LinuxではNULLが返ってくることはないというのが理由らしいんだけど。
2013/02/03(日) 14:07:34.43
成功した振りして使用時に落ちるの何とかして欲しい
2013/02/03(日) 14:11:47.93
OOM Killerで他のプロセスが殺されるとか、糞仕様すぎる。
58デフォルトの名無しさん
垢版 |
2013/02/03(日) 14:23:36.91
>>44
> 馬鹿死ね
> K&R1 からだ
古い規格に詳しいな、ジジイ。 で、それが何か? ｗｗｗｗ
2013/02/03(日) 14:29:16.84
反論できなくなると開き直る
60デフォルトの名無しさん
垢版 |
2013/02/03(日) 14:35:03.61
>>46
お前がオレさまの相手をするのは、バカすぎて無理。ｗｗｗｗｗ
うんこQzからかって遊ぶだけにとどめておけ。ｗｗｗｗ

その処理系のライブラリが
inline void free(void *p)
{
if (p)
read_free(p);
}

という実装だったら、
> if(p!=NULL)free(p);
はコンパイラが最適化できる。 ｗｗｗｗ
61デフォルトの名無しさん
垢版 |
2013/02/03(日) 14:44:15.39
>>59
> realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話であればこれは有名
「これは有名」の「これ」とは何かね? ｗｗｗｗ
バカの文章は読みにくい。 ｗｗｗｗ
2013/02/03(日) 14:50:20.19
>>45
コンパイラが最適化してくれるというのは、そうかも知れない。
でも、しないかもしれない。
また、それは可読性を下げてまでやるべき事ではないと思うがな。
もしかして IOCCC に出品するつもりとか？

そして、やり方としては、無茶な仕事を下請けへ丸投げするのと
全く同じなんだよね。

技術的な裏付けは何にも無いけど、彼奴等に投げておけば
何とかするだろう、レベルの発想。
2013/02/03(日) 15:10:49.37
>>62
えっと、if文１個式１つで可読性が悪くなるとか、
頭悪いんですか？悪いんですね。
2013/02/03(日) 15:16:54.70
>>55
そうなのか？少なくともヒープとして使えるメモリ空間使い果たせば返ってくるだろ。
>>56,57
vm.overcommit_memory あたりでググってみるといいかも。
ただでっかいメモリ空間を使っているプロセスから fork & exec していたりする時は注意。
65デフォルトの名無しさん
垢版 |
2013/02/03(日) 15:20:11.25
それは↓を言う前に言うべきだったね。 ｗｗｗｗ
自信たっぷりに否定した後で、可能な事を示されてからじゃ遅い。 ｗｗｗｗ
お前はヘボなんだよ。ｗｗｗｗ ヘボ同士でうんこQzと絡んでるのがお似合い。ｗｗｗｗ

本日のバカ ｗｗｗｗ
> From: [46] デフォルトの名無しさん <sage>
> Date: 2013/02/03(日) 13:37:59.35
>
> >>45
> しない
> コンパイラからはfree() は単なる一つの関数にしかみえない
> p が 0 のとき free(p) はなにもしないことは、コンパイラはしらない
> 勉強不足だ、これではwww野郎やQZすらの相手にもならない
>
> 死ね

>>45は前スレのオレの真似をして煽っただけだろう。
十中八九inlineで最適化なんて思いついていない中防。。
そんなのに釣られてバカ晒す事になった>>46が憐れでならない。 ｗｗｗｗｗ
2013/02/03(日) 15:21:08.32
全ては、その１個の積み重ねなのだよ。
2013/02/03(日) 15:22:16.73
>>62
呼ばなくていいなら関数呼び出しは少ないほうがいい場合もある。
そういう意味でif (p) free(p)は、意味はある。
機械語にしたところでfreeを呼ぶためにレジスタにロードするので
zeroチェックはそのついでで行うことができるし、ifのほうは
大したペナルティにはならない。
2013/02/03(日) 15:26:10.39
freeがinlineになっているクソな処理系ってなんだよ。
2013/02/03(日) 15:28:33.30
>>64
linux上でman mallocをよく読め。
2013/02/03(日) 15:32:20.46
>>67
NULLがzeroだなんて誰が決めたの？
2013/02/03(日) 15:36:01.30
ところで明日振り替え休日で休みだよね。
2013/02/03(日) 15:36:42.91
NULLは（仮に機械表現が全ビット0でなかったりしても）コンパイラ（言語）の上では0だよ？
そんなことも知らずにこんなスレで暴れようと思ってるの？
2013/02/03(日) 15:44:50.31
>>60
＞その処理系のライブラリが inline void free(void *p)
お前も馬鹿か？
標準ライブラリがソースで提供されているとでも？
普通はobjやlibではないか？
そんなバイナリをインラインにできるとでも？

死ね
2013/02/03(日) 15:46:58.24
>>73
#include <stdlib.h>
2013/02/03(日) 15:49:07.30
>>61
やさしい日本語しかよまない／よめない馬鹿なんだね、指示詞を敢えて差し込むのはよくやること
＞前項の目的を達するため､陸海空軍その他の戦力は**これを**保持しない。
＞国の交戦権は**これを**認めない。

>> realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話であればこれは有名
>「これは有名」の「これ」とは何かね? ｗｗｗｗ
「realloc(NULL, size); がmalloc(size) と等価にならないかわいそうなバグがある処理系が存在した話」
だね

死ね
2013/02/03(日) 15:50:47.38
>>74
死ね
2013/02/03(日) 15:52:02.57
>>71
ということにしたいのですね:-P
2013/02/03(日) 15:54:38.10
len = sprintf(buf, "%c", 0)
len => 1
strlen(buf) => 0
79デフォルトの名無しさん
垢版 |
2013/02/03(日) 15:56:25.84
>>75
で、それが、
「freeにNULLを与えた時の動作が規定されたのはC89ではなくてK&R1だ」となんの関係があるんだ? ｗｗｗｗ
2013/02/03(日) 15:59:48.45
しかしこのネタは昔から盛り上がるんだけれど、リアルで素のmallocをアプリレベルでそんなに呼ぶものなのか?

組み込み云々言っている奴もいたけれど、俺が関わってきた範囲では分断の問題で直接使うことはないな。
素のmalloc/freeは遅くて使い物にならないって環境って場合もあったけど。
最近はRAM自体はそこそこのっている環境も多いんでスタック増やして、C99にして可変長配列使うっていう手で
かなりの部分が楽になった。

人命云々言っている奴、プロセスの概念がある世界ならば、なるべくプロセスの寿命を短くするって方向も
考えたほうがいいぞ。最初からmalloc/freeだけに限らずバグの全くない大規模なプログラムなんて
妄想だと思ってシステム作ると、頑強なものができるから。
81デフォルトの名無しさん
垢版 |
2013/02/03(日) 16:09:57.63
マルチスレッドだと、スタックサイズが固定になるのでautoにでかいのを置くことは
必然的に避ける事になる。 これ位は常識だぞ。 ｗｗｗｗ

> 最初からmalloc/freeだけに限らずバグの全くない大規模なプログラムなんて
free楽勝と豪語しているfree必須バカは全くバグのないプログラムを作れるらしいぞ。ｗｗｗｗ
2013/02/03(日) 16:14:07.11
>>69
>>65のどの部分がおかしいか教えてくれ。マジでわからん。
vm.overcommit_memory=2 でも malloc が成功しても実際には使えないことがあるってことか?
2013/02/03(日) 16:14:49.26
>マルチスレッドだと、スタックサイズが固定になる

無知発見ｗ
2013/02/03(日) 16:15:58.26
＞リアルで素のmallocをアプリレベルでそんなに呼ぶものなのか
＞素のmalloc/freeは遅くて使い物にならないって環境って場合もあったけど

自分が特殊な環境にいたと自負してる時点で1行目が死んでるよ
2013/02/03(日) 16:18:17.34
>>82
はい。
Linuxの楽観的メモリ管理はその程度ではどうにもなりません。
86デフォルトの名無しさん
垢版 |
2013/02/03(日) 16:20:58.63
>>83
あっそ、pthreadでもWin32でもスレッド生成時のスタックサイズを超える事は出来ないけど、
それを伸ばしてくれるスレッドライブラリってどれだよ。ｗｗｗ
2013/02/03(日) 16:22:02.44
>>82
いや、常識的にユーザーにその設定書き換えてくださいとは言えないだろ…
root権限ないとだめだし自分のプログラムだけに影響するわけでもないし
2013/02/03(日) 16:22:30.71
>>81
> マルチスレッドだと、スタックサイズが固定になるのでautoにでかいのを置くことは
> 必然的に避ける事になる。 これ位は常識だぞ。 ｗｗｗｗ

おいおい、組み込みの世界だと元々スタック1Kとかふつーだったのが、それを64Kにすれば
楽できるとかそういうレベルの話だよ。
2013/02/03(日) 16:23:37.58
>>86
>スレッド生成時のスタックサイズを超える事は出来ない

生成時には可変であることを認めましたね？おバカさんｗ
2013/02/03(日) 16:25:47.94
死ねの人は息してる？ｗ
2013/02/03(日) 16:27:24.50
>>79
関係ないね。この超有名な話と混同しているのではないかと勘繰っただけでね
死ね
2013/02/03(日) 16:29:53.55
>>80
確かに素のmalloc()/free() を直にソースに散らばらせるのは好ましくないね
QZですらアロケータ経由だったようだし
昔のlisp処理系ではタイプごとにアロケータを別に準備していたようだねセル用とかね64KiBのシステム用だったけれど
2013/02/03(日) 16:30:48.52
>>55
32ビットだとメモリ空間は4Gだろ。32ビットlinuxでmalloc(1M)を繰り返すと、
4097回目には何が返ってくる?
ああ、返さずに自殺という選択肢もあるか。
2013/02/03(日) 16:31:17.25
>>81
>free楽勝と豪語しているfree必須バカは全くバグのないプログラムを作れるらしいぞ。ｗｗｗｗ
楽勝とはいっていないがmalloc()/free()くらいは完全に管理できるだろうねアロケータを準備したりしてね
お前はそれができないからmalloc()/free()を使わないんだろう？
死ね
2013/02/03(日) 16:32:12.21
>>86
スレッド生成時には好きに変えられるんだ馬鹿
死ね
■ このスレッドは過去ログ倉庫に格納されています
5ちゃんねるの広告が気に入らない場合は、こちらをクリックしてください。
ニューススポーツなんでも実況