Re: New Defects reported by Coverity Scan for XenProject

[Jan Beulich <jbeulich@xxxxxxxx>]

On 08.09.2025 13:04, Alejandro Vallejo wrote:
> 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.
> 
> 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?

And with any other non-zero values of "size" here.

Jan