On Mon, Jun 03, 2019 at 04:31:51PM +0200, Andrea Bolognani wrote:
On Mon, 2019-06-03 at 14:10 +0200, Ján Tomko wrote:On Fri, May 31, 2019 at 05:22:00PM +0200, Andrea Bolognani wrote: > + if (a->nbits < b->nbits && > + virBitmapExpand(a, b->nbits) < 0) { After this, 'b' can hold b->nbits and 'a' can hold b->nbits+1. if (b->nbits && a->nbits < b->nbits && virBitmapExpand(a, b->nbits -1) < 0) {Yeah, you're right, we need to account for the zero-indexing of bits. I mean, it's not like the resulting bitmap would be incorrect either way, but we might end up allocating more memory than it's actually required.
Actually I do think it would be incorrect. The bitmap size is as important as its values - e.g. if the resulting bitmap had 4 set bits, a size of 4 vs 5 would alter the result of virBitmapIsAllSet. It would only be a marginal over-allocation if we were dealing with map_len.
The first check seems unnecessary, though: the only case in which the argument to virBitmapExpand() would be incorrect is b->nbits == 0, but we know that both a->nbits and b->nbits are >= 0 and we also just verified that a->nbits < b->nbits, so b->nbits must be >= 1 and the argument to virBitmapExpand() will always be correct. Or am I missing something?
Right, it will work unless someone changes nbits from size_t to double. Jano
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
