Re: New Defects reported by Coverity Scan for XenProject

[Alejandro Vallejo <alejandro.garciavallejo@xxxxxxx>]

On Mon Sep 8, 2025 at 12:19 PM CEST, Jan Beulich wrote:
> On 07.09.2025 16:37, scan-admin@xxxxxxxxxxxx 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