アカウント名:
パスワード:
あらら、これ rsync だけの問題で終わるのかしらん?
改めてパッチを見たところ、メモリ割り当て関連コードが、
で全て書き直されていますね(C++ か
また、メモリの割り当て最大サイズが 1GB に制限されています(こちらは DoS 対策か)。
これは
+#define MALLOC_MAX 0x40000000
と、_new_array、_realloc_arrayの
+ if (num >= MALLOC_MAX/size) + return NULL; (これは2ヶ所)
の部分のことですか?。これは単なる桁あふれ対策に見えま
batch_flist->malloced *= 2;
してメモリ再確保とかしているので、
というかんじでリリースしたのかなあと…
まあ安全側に振る分にはいいかもしれないんですが、どちらかというとこういうところで0x7FFFFFFFとか0x40000000とかいった数字をじかに書いてるのが心配だったり…
あと、0x40000000Byteは1GB(あるいは1GiB)だと思う。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人
何これ? (スコア:2, 参考になる)
改めてパッチを見たところ、メモリ割り当て関連コードが、
で全て書き直されていますね(C++ か
Re:何これ? (スコア:2, 興味深い)
これは
と、_new_array、_realloc_arrayの
の部分のことですか?。これは単なる桁あふれ対策に見えま
巧妙に潜伏したバグは心霊現象と区別が付かない。
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, 興味深い)