> -----Original Message-----
> From: Peter Maydell <peter.mayd...@linaro.org>
> Sent: Friday, November 5, 2021 10:31 AM
> To: Taylor Simpson <tsimp...@quicinc.com>
> Cc: qemu-devel@nongnu.org; Richard Henderson
> <richard.hender...@linaro.org>; Philippe Mathieu-Daudé
> <f4...@amsat.org>
> Subject: Re: FW: New Defects reported by Coverity Scan for QEMU
>
> On Thu, 4 Nov 2021 at 22:34, Taylor Simpson <tsimp...@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
