Czy kod źródłowy kompresji LZ4 jest zgodny z 64-bitowym?

Question

Właśnie pobrałem źródła kompresji LZ4-HC i sprawdziłem je pod kątem zgodności 64-bitowej.

I'am się kilka ostrzeżeń "konwersji z '__int64' do 'unsigned int', ewentualnej utraty danych"

Kiedy trzymałem kopanie zauważyłem makro ADD_HASH (P). Ostatnia część tego makra jest

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) 

Co się dzieje na 32 bit - odejmiemy const int ze wskaźnikiem i przechowywania do innego wskaźnika - wystarczająco bezpieczny.

Teraz 64: Wydaje mi się, że odjęcie dwóch wskaźników na 64 i zapisanie ich w U32 nie jest wcale bezpieczne!

Rozumiem, że LZ4 jest kompatybilny ze standardem 64-bitowym tylko wtedy, gdy gwarantuje, że "p" i "baza" nie są daleko od siebie ... a teraz muszę zagłębić się w logikę, aby to sprawdzić.

Czy coś mi umknęło? Czy ktokolwiek sprawdził tę bibliotekę pod kątem pełnej kompatybilności z 64-bitami, jak twierdził? Jakieś inne znane problemy z kodem biblioteki?

Answer 1

LZ4 ma być kompatybilny z 64 bitami. Był już wielokrotnie testowany.

LZ4-HC jest nieco bardziej skomplikowany i być może pozostały jakieś ostrzeżenia kompilatora. Możesz je zgłosić na liście problemów: http://code.google.com/p/lz4/issues/list

Odjęcie 2 wskaźników ma być typem size_t. size_t ma 64 bity na 64-bitowym CPU. Przesyłanie wyniku do 32 bitów może spowodować problem z przepełnieniem.

Jest to jednak mało prawdopodobne. LZ4 działa w oknie 64 KB. Co oznacza, że ​​wszelkie odniesienia powyżej 64 KB są pomijane. Aby odniesienie do bardzo długiego zasięgu mogło stać się problemem, musiałoby to być dokładnie 4 GB + kilka KB. Ponadto, ponieważ wymienione są odniesienia, konieczne jest, aby było absolutnie zerowe odniesienie między < 64KB i> 4 GB przy użyciu tego samego skrótu. Jest to również bardzo mało prawdopodobne.

Nawet wtedy, gdy taki przypadek mógłby zostać celowo sfałszowany, efekt końcowy jest taki, że sprężarka zostanie "napomknięta" w kierunku pozycji, która nie jest zgodna. I odrzuci go w operacji porównania.

Jedynym minusem jest ryzyko utraty kilku cykli procesora przy bezużytecznym porównaniu. Całkiem uczciwie.

Zawsze lepiej jest usunąć "ostrzeżenia kompilatora", gdy jest "prawie za darmo". Niemal dowolne tłumaczenie na: brak utraty wydajności i znikomy wpływ na złożoność kodu.