RE: FW: New Defects reported by Coverity Scan for QEMU

[Taylor Simpson]

> -----Original Message-----
> From: Peter Maydell <peter.maydell@linaro.org>
> Sent: Friday, November 5, 2021 10:31 AM
> To: Taylor Simpson <tsimpson@quicinc.com>
> Cc: qemu-devel@nongnu.org; Richard Henderson
> <richard.henderson@linaro.org>; Philippe Mathieu-Daudé
> <f4bug@amsat.org>
> Subject: Re: FW: New Defects reported by Coverity Scan for QEMU
> 
> On Thu, 4 Nov 2021 at 22:34, Taylor Simpson <tsimpson@quicinc.com> wrote:
> >
> > Coverity is getting confused here.  The index can never actually overflow.
> >  Does Coverity have a pragma or something to tell it it's OK?
> >
> > The loop nest in question is (the index must be < 128)
> >     for (int offset = 1; offset < 128; offset <<= 1) {
> >         for (int k = 0; k < 128; k++) {
> >             if (!(k & offset)) {
> >                 swap(vector1.ub[k], vector0.ub[k + offset]);
> >             }
> >         }
> >     }
> > Basically, it's looking for elements to swap, and the "if (!(k &
> > offset))" prevents "k + offset" from overflowing.
> 
> Yes, I agree this is a false positive. I've marked it as an FP in the 
> Coverity web
> UI.
> 
> I suspect that changing "k + offset" to "k | offset" would probably stop
> Coverity complaining, but we should only do that if you think it's more
> readable that way. (As I read the code we are doing bit operations here
> rather than addition, so it seems slightly better to be using the OR; but
> there's not a lot in it.)

Thanks Peter!

I prefer to leave the code as-is.

Taylor