Il codice sorgente per la compressione LZ4 è compatibile con 64 bit?

Question

Ho appena scaricato le fonti per la compressione LZ4-HC e il controllo per la compatibilità a 64 bit.

I'am ottenere alcuni avvertimenti "di conversione da '__int64' a 'unsigned int', possibile perdita di dati"

Quando ho tenuto a scavare ho notato macro ADD_HASH (p). Ultima parte di quella macro è

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) 

Quello che sta accadendo su 32 bit - sottraiamo int const da un puntatore e la memorizzazione in un altro puntatore - abbastanza sicuro.

Ora 64: Mi sembra che sottrarre due puntatori su 64 e salvarli in U32 non sia affatto sicuro!

La mia comprensione del fatto che LZ4 è compatibile con 64 bit solo se è garantito che "p" e "base" non sono distanti ... e ora devo scavare più a fondo nella logica per verificarlo.

Mi sono perso qualcosa? Qualcuno ha controllato questa libreria per la piena compatibilità a 64 bit come affermava di essere? Qualche altro problema con il codice della biblioteca?

Answer 1

LZ4 deve essere compatibile a 64 bit. È già stato testato numerose volte.

LZ4-HC è un po 'più complesso, e forse ci sono alcuni avvisi del compilatore rimasti. Sentitevi liberi di informarli sulla lista di problemi: http://code.google.com/p/lz4/issues/list

La sottrazione di 2 puntatori dovrebbe essere un tipo size_t. size_t è 64 bit su 64 bit CPU. La trasmissione del risultato a 32 bit può pertanto creare un problema di overflow.

Questo è comunque improbabile. LZ4 funziona su una finestra da 64 KB. Il che significa che qualsiasi riferimento oltre 64 KB viene ignorato. Per un riferimento a un intervallo molto lungo, il problema dovrebbe essere esattamente 4 GB + pochi KB. Inoltre, poiché i riferimenti sono elencati, è necessario che ci sia assolutamente zero riferimento tra < 64 KB e> 4 GB utilizzando lo stesso hash. Anche questo è estremamente improbabile.

Anche in questo caso, se un caso del genere può essere intenzionalmente contraffatto, l'effetto finale è che il compressore sarà "accennato" a una posizione che non è una corrispondenza. E lo scartare a confronto operazione.

Quindi l'unico svantaggio è il rischio di perdere alcuni cicli della CPU su un confronto inutile. Equo.

Tuttavia, è sempre meglio rimuovere "avvisi del compilatore" ogni volta che è "quasi libero". Quasi libero di essere tradotto in: nessuna perdita di prestazioni e impatto trascurabile sulla complessità del codice.