アカウント名:
パスワード:
あらら、これ rsync だけの問題で終わるのかしらん?
また、メモリの割り当て最大サイズが 1GB に制限されています(こちらは DoS 対策か)。
+#define MALLOC_MAX 0x40000000
+ if (num >= MALLOC_MAX/size) + return NULL; (これは2ヶ所)
batch_flist->malloced *= 2;
してメモリ再確保とかしているので、
というかんじでリリースしたのかなあと…
まあ安全側に振る分にはいいかもしれないんですが、どちらかというとこういうところで0x7FFFFFFFとか0x40000000とかいった数字をじかに書いてるのが心配だったり…
あと、0x40000000Byteは1GB(あるいは1GiB)だと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
192.168.0.1は、私が使っている IPアドレスですので勝手に使わないでください --- ある通りすがり
何これ? (スコア:2, 参考になる)
また、メモリの割り当て最大サイズが 1GB に制限されています(こちらは DoS 対策か)。GNU libc に問題があるのでしょうか?
Re:何これ? (スコア:2, 興味深い)
これは と、_new_array、_realloc_arrayの の部分のことですか?。これは単なる桁あふれ対策に見えますが。 32ビットに固定しているのは楽をするためでしょうか。
# ちなみに1Gじゃなくて10Gですね。
……と思ったんですが、桁あふれ対策なら0x7FFFFFFFにしますね。(0xFFFFFFFFではないのは、size_tが符号つきの場合のことを考えてのこと)
ん~、やっぱり謎だ。
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:何これ? (スコア:2, すばらしい洞察)
batch_flist->malloced *= 2;
してメモリ再確保とかしているので、
というかんじでリリースしたのかなあと…
まあ安全側に振る分にはいいかもしれないんですが、どちらかというとこういうところで0x7FFFFFFFとか0x40000000とかいった数字をじかに書いてるのが心配だったり…
あと、0x40000000Byteは1GB(あるいは1GiB)だと思う。
-- Takehiro TOMINAGA // may the source be with you!
size_t(オフトピ気味) (スコア:1)
size_tが最低32ビット(longの最低保証されるされるサイズ)はあると仮定するのは問題ないと思ってましたが、今調べたら、符号なし整数としか定義されていないんですね。迂闊でした。
ということは、size_tのサイズが8ビット(shortの最低保証されるサイズ、16ビットより小さかったりしますが、charも整数に変わりはありませんし)な処理系があってもいいわけですね。最大255バイトしか確保できないmallocなんてヤですが。
ということは、size_tのサイズを調べて、それが表現できる最大の整数を調べるのが正しい道ですかね。
もっとも、rsyncを動かすような環境用の処理系なら、size_tのサイズが32ビット以上だと仮定しても問題ないとは思います。(←その発想が危険か……)
この辺、パッチを書いた方も同じような誤解をしているんでしょうかね。
-- 理解が不十分なことや推測をたれ流してしまったので、偉い人降臨ぷりーず
巧妙に潜伏したバグは心霊現象と区別が付かない。
Re:size_t(オフトピ気味) (スコア:2, 興味深い)
Re:何これ? (スコア:0)