5

我刚刚下载了 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 根本不安全！

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

我错过了什么吗？有没有人检查这个库是否像它声称的那样完全兼容 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 适用于 64 KB 窗口。这意味着，任何超过 64KB 的引用都将被忽略。要使一个非常长的范围参考成为问题，它需要正好是 4GB + 几 KB。此外，由于列出了引用，因此必须在 < 64KB 和 > 4GB 之间使用相同的散列绝对零引用。这也是极不可能的。

即使这样，如果可以故意伪造这种情况，最终效果是压缩机将被“提示”到不匹配的位置。并将在比较操作中丢弃它。

所以唯一的缺点是在无用的比较中丢失几个 CPU 周期的风险。很公平。

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

于 2012-10-20T15:17:04.190 回答