On 18/01/2018 14:36, Daniel P. Berrange wrote:
>>> +/*
>>> + * Figure out how much pending data we should allow in the output
>>> + * buffer before we throttle incremental display updates, and/or
>>> + * drop audio samples.
>>> + *
>>> + * We allow for equiv of 1 full display's worth of FB updates,
>>> + * and 1 second of audio samples. If audio backlog was larger
>>> + * than that the client would already suffering awful audio
>>> + * glitches, so dropping samples is no worse really).
>>> + */
>>> +static void vnc_update_throttle_offset(VncState *vs)
>>> +{
>>> + size_t offset =
>>> + vs->client_width * vs->client_height *
>>> vs->client_pf.bytes_per_pixel;
>> because the multiply is done with the "int" type, and then may
>> be sign-extended when converted to the probably-64-bit unsigned
>> size_t, resulting in the high bits all being set if the
>> multiply ended up with a 1 in bit 31.
> I guess we can usefully change client_width/client_height to be an unsigned
> int, since there's no valid scenario for them to be negative.
In addition to that, do we support a >= 2 GiB framebuffer at all? (Even
with unsigned ints, Coverity would rightly complain about a truncated
32-bit multiplication being assigned to a 64-bit value).
Paolo
