Comparison of base_blob (uint256) starts from the most right bits #9515

I faced very strange problem with the base_blob. Example:

LogPrintf("Start to test uint256.\n");
auto targetValue = uint256S("0x000000ffffffffffffffffffffffffffffffffffffffffffffffffffffffffff");
auto testValue01 = uint256S("0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff");
auto testValue02 = uint256S("0x69143d2202526eaa843cddbeb8c08ae66d61c73a63ecf5b762d107dd07fe5c3e");
auto testValue03 = uint256S("0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000");
auto testValue04 = uint256S("0x000000ffffffffffffffffffffffffffffffffffffffffffffffffffffff0000");
auto testValue05 = uint256S("0x0000000000ffffffffffffffffffffffffffffffffffffffffffffffffffffff");
LogPrintf("Test 01 - %d\n", (testValue01 < targetValue));
LogPrintf("Test 02 - %d\n", (testValue02 < targetValue));
LogPrintf("Test 03 - %d\n", (testValue03 < targetValue));
LogPrintf("Test 04 - %d\n", (testValue04 < targetValue));
LogPrintf("Test 05 - %d\n", (testValue05 < targetValue));
LogPrintf("Finished to test uint256\n\n\n");

Result - 0, 1, 1, 1, 1. I.e. testValue01bigger, testValue02..05 smaller than targetValue. But correct values - 0, 0, 0, 1, 1

Seems that comparison of uint256 starts from the most right bits. I have no other explanation of test results. Is it a bug? What am I misreading?

Tested commit - most recent in the branch 0.13 (77eaadb) Ubuntu 16.04

The comparison of base_blob compares the internal binary representation lexicographically - which is fast and good enough for maps and such. There it doesn't matter what the sorting is, as long as there is some order.

If you intend to compare 256-bit integers you should use arith_uint256.

ooops. sorry