Question

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

我收到的警告很少“从'__64'转换为'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。此外，由于列出了参考文献，因此＆lt;之间必须存在绝对零参考。 64KB和> 4GB使用相同的哈希值。这也是极不可能的。

即便如此，如果这种情况可能是故意伪造的，最终效果是压缩机将“暗示”朝向不匹配的位置。并将在比较操作中丢弃它。

因此唯一的缺点是在无用的比较中失去一些CPU周期的风险。相当公平。

尽管如此，只要“几乎免费”，删除“编译器警告”总是更好。几乎免费被翻译成：不会损失性能，对代码复杂性的影响可以忽略不计。

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

1 个答案: