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> Reviewed-by: Paolo Bonzini <pbonz...@redhat.com> Message-id: 20181005133012.26490-1-peter.mayd...@linaro.org --- 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); -- 2.19.0