pete4abw / lrzip-next

get_magic_v8 uses a logical && operation instead of the & bitwise operation, resulting in the if condition being dependant on the whole magic[17] value.

lrzip-next/src/lrzip.c

Line 365 in 9f2257d

else if (magic[17] && 0b10000000) // zpaq block and compression level stored

Thanks. Eagle Eyes @pietroborrello. FORTUNATELY, the lzma test comes first and no one uses bzip, gzip, or lzo for compression ;-) . Will fix for the next push.

 362         if (magic[17] > 0 && magic[17] <= 40)   // lzma dictionary
 363         {
 364                 control->dictSize = LZMA2_DIC_SIZE_FROM_PROP(magic[17]);        // decode dictionary
 365                 control->lzma_properties[0] = LZMA_LC_LP_PB;                    // constant for lc, lp, pb 0x5D
 366                 /* from LzmaDec.c */
 367                 for (i = 0; i < 4; i++)                                         // lzma2 to lzma dictionary expansion
 368                         control->lzma_properties[1 + i] = (Byte)(control->dictSize >> (8 * i));
 369         }
 370         else if (magic[17] && 0b10000000)       // zpaq block and compression level stored
 371         {
 372                 control->zpaq_bs = magic[17] & 0b00001111;      // low order bits are block size
 373                 magic[17] &= 0b01110000;                        // strip high bit
 374                 control->zpaq_level = magic[17] >> 4;           // divide by 16
 375         }

fixed in lzma-21.06 (default branch)

:lady_beetle: [use of logical '&&' instead of bitwise '&' operation]