Re: New Defects reported by Coverity Scan for XenProject

[Jan Beulich <jbeulich@xxxxxxxx>]

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