[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH v6 09/20] parallels: Switch to .bdrv_co_block_st

From: Vladimir Sementsov-Ogievskiy
Subject: Re: [Qemu-block] [PATCH v6 09/20] parallels: Switch to .bdrv_co_block_status()
Date: Tue, 12 Dec 2017 19:49:06 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0

12.12.2017 19:32, Eric Blake wrote:
On 12/11/2017 09:24 AM, Vladimir Sementsov-Ogievskiy wrote:

On the other hand, '<< BDRV_SECTOR_BITS' only produces the same size
output as the input; if the left side is 32 bits, it risks overflowing.
But '* BDRV_SECTOR_SIZE' always produces a 64-bit value.  So I've
learned (from past mistakes in other byte-conversion series) that the
multiply form is less likely to introduce unintended truncation bugs.
hm, now I doubt. I've wrote tiny program:

#include <stdint.h>
#include <stdio.h>

int main() {
     uint32_t blocks = 1 << 20;
     int block_bits = 15;
     uint32_t block_size = 1 << block_bits;
     uint64_t a = blocks * block_size;
     uint64_t b = blocks << block_bits;
     uint64_t c = (uint64_t)blocks * block_size;
Not the same.  'block_size' in your code is 'uint32_t', so your
multiplication is still 32-bit if you don't cast blocks; while qemu has::

include/block/block.h:#define BDRV_SECTOR_BITS   9
include/block/block.h:#define BDRV_SECTOR_SIZE   (1ULL << BDRV_SECTOR_BITS)

and the 1ULL in the qemu definition forces 'unsigned long long' results
whether or not you cast.

Ah, cool, missed this. And we can't do such thing for BDRV_SECTOR_BITS because it will be unspecified behavior.
Thank you for explanation.

Best regards,

reply via email to

[Prev in Thread] Current Thread [Next in Thread]