c++ - LZ4 压缩的源代码是否兼容 64 位？

Question

我刚刚下载了 LZ4-HC 压缩源并检查了它的 64 位兼容性。

我收到的警告很少“从‘__int64’到‘unsigned int’的转换，可能会丢失数据”

当我继续挖掘时，我注意到宏 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 位发生了什么——我们从指针中减去 const int 并存储到另一个指针中——足够安全。

现年 64 岁: 在我看来，在 64 上减去两个指针并将它们保存到 U32 中是完全不安全的!

我的理解是 LZ4 只有在保证“p”和“base”相距不远的情况下才兼容 64 位...现在我必须更深入地研究逻辑来检查这一点。

我错过了什么吗？有人检查过这个库是否像它声称的那样完全兼容 64 位吗？还有其他关于图书馆代码的问题吗？

Answer 1

LZ4 应该是 64 位兼容的。它已经过多次测试。

LZ4-HC 有点复杂，可能还有一些编译器警告。 请随时在问题列表中通知他们:http://code.google.com/p/lz4/issues/list

2个指针相减应该是size_t类型。 size_t 在 64 位 CPU 上是 64 位。 因此，将结果转换为 32 位可能会产生溢出问题。

但这不太可能。 LZ4 适用于 64 KB 窗口。这意味着，任何超过 64KB 的引用都将被忽略。对于成为问题的超长范围引用，它需要恰好是 4GB + 几 KB。 此外，由于列出了引用，因此使用相同散列的 < 64KB 和 > 4GB 之间的引用绝对为零是必要的。这也是极不可能的。

即便如此，如果可以故意伪造这种情况，最终结果是压缩器将被“暗示”到一个不匹配的位置。并将在比较操作时丢弃它。

因此，唯一的缺点是在无用的比较中可能会损失几个 CPU 周期。相当公平。

尽管如此，当它“几乎免费”时，最好删除“编译器警告”。几乎免费被翻译成:没有性能损失，对代码复杂性的影响可以忽略不计。