On 05/10/2018 15:30, Peter Maydell wrote:
> Coverity complains (CID 1395628) that the multiply in the calculation
> of the framebuffer base is performed as 32x32 but then used in a
> context that takes a 64-bit hwaddr. This can't actually ever
> overflow the 32-bit result, because of the constraints placed on
> the s->config values in bcm2835_fb_validate_config(). But we
> can placate Coverity anyway, by explicitly casting one of the
> inputs to a hwaddr, so the whole expression is calculated with
> 64-bit arithmetic.
>
> Signed-off-by: Peter Maydell <peter.mayd...@linaro.org>
> ---
> This is one of those cases where I was 50/50 about whether to just
> mark the coverity issue as a false-positive.
Agreed, but in the end it's not too much noise, so
Reviewed-by: Paolo Bonzini <pbonz...@redhat.com>
Thanks,
Paolo
> hw/display/bcm2835_fb.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/hw/display/bcm2835_fb.c b/hw/display/bcm2835_fb.c
> index d534d00a65f..599863e4e17 100644
> --- a/hw/display/bcm2835_fb.c
> +++ b/hw/display/bcm2835_fb.c
> @@ -190,7 +190,7 @@ static void fb_update_display(void *opaque)
> }
>
> if (s->invalidate) {
> - hwaddr base = s->config.base + xoff + yoff * src_width;
> + hwaddr base = s->config.base + xoff + (hwaddr)yoff * src_width;
> framebuffer_update_memory_section(&s->fbsection, s->dma_mr,
> base,
> s->config.yres, src_width);
>
