On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote: > On 07.09.2025 16:37, [email protected] 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
The offending line LGTM too. The only credible explanation I can think of is Coverity flagging discarded 1s on left shifts as loss of precision. If so, "~((1 << size) - 1)", or "(~0UL >> size) << size" should make it happy, but surely that error would flare up with all uses of GENMASK() too? Cheers, Alejandro
