5

LZ4-HC圧縮のソースをダウンロードし、64ビットの互換性を確認しました。

「'__int64'から'unsignedint'への変換、データが失われる可能性がある」という警告がほとんど表示されません。

掘り続けてみると、マクロADD_HASH（p）に気づきました。そのマクロの最後の部分は

HashTable[HASH_VALUE(p)] = (p) - base;

p - const BYTE*
base - const BYTE* const for 64-bit.   (const int b - for 32-bit)
HTYPE HashTable[];
HTYPE is U32 for 64-bit platform       (const BYTE* - for 32-bit)

32ビットで何が起こっているか-ポインタからconstintを減算し、別のポインタに格納する-十分に安全です。

現在64：64で2つのポインターを減算し、それらをU32に保存することは、まったく安全ではないように思われます。

LZ4が64ビット互換であるという私の理解は、「p」と「base」がそれほど離れていないことが保証されている場合にのみ...そして今、それをチェックするためにロジックを深く掘り下げる必要があります。

私は何かを逃しましたか？誰かがこのライブラリをチェックして、64ビットの完全な互換性を確認しましたか？ライブラリのコードに関する他の既知の問題はありますか？

4

1 に答える 1

2

LZ4は64ビット互換であると想定されています。すでに何度もテストされています。

LZ4-HCはもう少し複雑で、コンパイラの警告が残っている可能性があります。問題リストで自由に通知してください：http ：//code.google.com/p/lz4/issues/list

2つのポインターの減算は、size_tタイプであると想定されています。size_tは、64ビットCPUでは64ビットです。したがって、結果を32ビットにキャストすると、オーバーフローの問題が発生する可能性があります。

ただし、これはありそうにありません。LZ4は64KBウィンドウで動作します。つまり、64KBを超える参照は無視されます。非常に長い範囲の参照が問題になるには、正確に4GB+数KBである必要があります。さらに、参照がリストされているため、同じハッシュを使用して<64KBと>4GBの間で参照が完全にゼロである必要があります。これも非常にありそうにありません。

それでも、そのようなケースが意図的に偽造される可能性がある場合、最終的な効果は、コンプレッサーが一致しない位置に向かって「ヒント」されることです。そして、比較操作でそれを破棄します。

したがって、唯一の欠点は、役に立たない比較で数CPUサイクルを失うリスクです。かなり公平。

それでも、「ほぼ無料」の場合は常に「コンパイラの警告」を削除することをお勧めします。ほぼ無料で次のように変換されます：パフォーマンスの低下がなく、コードの複雑度への影響はごくわずかです。

于 2012-10-20T15:17:04.190 に答える