On Mon, Jun 03, 2019 at 05:04:51PM +0200, Andrea Bolognani wrote:
On Mon, 2019-06-03 at 16:43 +0200, Ján Tomko wrote:
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:
> > if (b->nbits &&
> > a->nbits < b->nbits &&
> >
On Mon, 2019-06-03 at 16:43 +0200, Ján Tomko wrote:
> 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:
> > > if (b->nbits &&
> > > a->nbits < b->nbits &&
> > > virBitmapExpand(a, b->nbits -1) < 0) {
> >
> > Yeah,
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
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 &&
>
On Fri, May 31, 2019 at 05:22:00PM +0200, Andrea Bolognani wrote:
The original implementation is extremely straightforward but
not too efficient, because it uses the public API instead of
poking the innards directly. This second implementation does
the latter, and as a consequence can afford to
The original implementation is extremely straightforward but
not too efficient, because it uses the public API instead of
poking the innards directly. This second implementation does
the latter, and as a consequence can afford to make @b const,
which is nice even though most existing virBitmap