LZ4壓縮64位兼容的源代碼？

我剛剛下載了LZ4-HC壓縮的源代碼並檢查它是否具有64位兼容性。LZ4壓縮64位兼容的源代碼？

我'得到一些警告「從‘__int64’到‘無符號整型’，可能丟失數據的轉換」

當我不停地挖，我注意到宏觀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位兼容性，因爲它聲稱是？有關庫代碼的其他任何已知問題？

來源

2012-10-19 adspx5

LZ4應該是64位兼容的。它已經被無數次測試過了。

LZ4-HC有點複雜，也許還有一些編譯器警告。隨時在問題列表上通知他們：http://code.google.com/p/lz4/issues/list

2個指針的減法應該是size_t類型。64位CPU上的size_t是64位。將結果轉換爲32位可能會因此產生溢出問題。然而，這並不太可能。 LZ4適用於64 KB窗口。這意味着，超過64KB的任何引用都被忽略。對於成爲問題的很長範圍的參考，它將需要正好4GB +幾KB。但是，由於列出了引用，所以必須使用相同的散列，在< 64KB和> 4GB之間絕對爲零。這也是極不可能的。即使如此，如果這種情況可能是故意僞造的，最終效果是壓縮器將被「暗示」到不匹配的位置。並將在比較操作中丟棄它。

所以唯一的缺點是在無用的比較中可能會損失幾個CPU週期。很公平。

儘管如此，刪除「編譯器警告」總是更好，只要它「幾乎免費」。幾乎可以自由轉換爲：不會損失性能，並且對代碼複雜性的影響可以忽略不計。

來源

2012-10-20 15:17:04 Cyan

LZ4壓縮64位兼容的源代碼？

回答

相關問題