base_uint::operator&=(uint64 b) #616

uint256.h

base_uint& operator&=(uint64 b)
{
    pn[0] &= (unsigned int)b;
    pn[1] &= (unsigned int)(b >> 32);
    return *this;
}

I think this code is conceptually wrong if connected to the operator &=. It's good enough to be put in a separate function. The problem is that it's doing the "logical and" only on the first two uint. The other uint should be zeroed. For example the base_uint::operator==(const base_uint& a, uint64 b) do checks the other uint of the base_uint for 0. This problem isn't present with the ^= and the |= operators because anything ^ 0 = anything, and anything | 0 = anything.

I agree. The behaviour seems wrong.

Would fixing this break anything (i.e. it is used somewhere)? If not, you could make a pull request to fix it.

Yes, conceptually you are right. Anding with a 64 bit number will make it a 64-bit number and discard the rest.

However, are you very sure nothing relies on the current behavior?

(If not, I wonder why it is this way. Is it called in a fast/critical loop, making the overhead of zeroing significant?)

Looks like a bug to me. Perfect candidate for a unit test. Looks to me like this method (and all the rest of the bignum &= methods) is not used anywhere in the source.

If it is not used, wouldn't it be a good idea to remove it? (it's in git should we need it later...)

It's not used indeed; #870 deletes it.