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

Is the source code for LZ4 compression 64-bit compatible?

本文关键字：源代码 64位 LZ4 压缩      更新时间：2023-10-16

我刚刚下载了lz4-hc压缩的来源，并检查了64位兼容性。

我很少有人警告"从'__int64'转换为'unsigned int'，可能会丢失数据"

当我继续挖掘时，我注意到Macro 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"answers" base"不远的情况下，我的LZ4是64位兼容...现在我必须更深入地研究逻辑才能检查。

我错过了什么吗？是否有人检查了该库是否有声称的完整64位兼容性？还有其他知道图书馆代码的问题吗？

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周期的风险。很公平。

尽管如此，每当"几乎免费"时，最好删除"编译器警告"。几乎可以自由地翻译成：没有表现丧失，对代码复杂性的影响微不足道。

相关文章：