On 07.09.2025 16:37, scan-ad...@coverity.com wrote: > ** CID 1665362: Integer handling issues (INTEGER_OVERFLOW) > /xen/lib/find-next-bit.c: 104 in find_next_zero_bit() > > > _____________________________________________________________________________________________ > *** CID 1665362: Integer handling issues (INTEGER_OVERFLOW) > /xen/lib/find-next-bit.c: 104 in find_next_zero_bit() > 98 } > 99 if (!size) > 100 return result; > 101 tmp = *p; > 102 > 103 found_first: >>>> CID 1665362: Integer handling issues (INTEGER_OVERFLOW) >>>> Expression "0xffffffffffffffffUL << size", where "size" is known to be >>>> equal to 63, overflows the type of "0xffffffffffffffffUL << size", which >>>> is type "unsigned long". > 104 tmp |= ~0UL << size; > 105 if (tmp == ~0UL) /* Are any bits zero? */ > 106 return result + size; /* Nope. */ > 107 found_middle: > 108 return result + ffz(tmp); > 109 }
I cannot make sense of their claim. 0xffffffffffffffffUL << 63 is simply 0x8000000000000000UL, isn't it? Where's the overflow there? There also cannot be talk of a 32-bit build, or else ~0UL would have been transformed to 0xffffffffUL. Jan
