Fix comparison of different signedness warning

[linh2931]

Leap on Main branch compiles very clean on Ubuntu 20.02, with only two types and 27 instances of warnings. 26 of them are

/home/lh/work/leap-main/libraries/chainbase/include/chainbase/undo_index.hpp:524:23:    warning: comparison of integer expressions of different signedness: ‘uint64_t’ {aka ‘long unsigned int’} and ‘long int’ [-Wsign-compare]
  524 |          if( revision > std::numeric_limits<int64_t>::max() )
      |              ~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

It is unclear why _revision was defined as int64_t not uint64_t originally. Instead of changing _revision's type which might introduce other unforeseen problems, a safer way is to change if( revision > std::numeric_limits<int64_t>::max() ) to if( revision > static_cast<uint64_t>(std::numeric_limits<int64_t>::max()) ). This static_cast is valid, since std::numeric_limits<int64_t>::max()) is a positive fixed constant.

============= Final solution ===============

During the review, @heifner suggested the right solution is to change _revision to uint64_t as original assumption about int64_t no longer holds. The final solution is changing _revision to uint64_t

Resolves #10

[heifner]

I think this an ok quick fix to get rid of all the warnings. However, I think the correct fix is to change _revision to be an uint64_t and modify revision() and undo_stack_revision_range() to return uint64_t. The old version of chainbase used revision -1 as a flag. See https://github.com/EOSIO/chainbase/blob/759ca20e908b60e54eed463d0b2889f6e2108e71/include/chainbase/chainbase.hpp#L292
That is no longer the case, so this code could be simplified and made clearer as revision can no longer be negative.

[linh2931]

Thanks @heifner for the background information! I was afraid to change _revision to uint64_t.

I will do the right fix in this PR. This will prevent future confusions, remove all the related static_cast and make code cleaner.

[heifner]

I was a little concerned this might cause a consensus failure. However, according to https://en.cppreference.com/w/cpp/language/types Range of values section:

Prior to C++20, the C++ Standard allowed any signed integer representation, [...] [including] ones' complement or sign-and-magnitude.

However, all C++ compilers use two's complement representation, and as of C++20, it is the only representation allowed by the standard...

Therefore the memory layout of int64_t and uint64_t are the same in C++20 and should be the same in pre-C++20 if all compilers use two's complement.

[linh2931]

Thanks for digging into this further. As _revision has not reached std::numeric_limits<int64_t>::max() yet, its representation in both int64_t and uint64_t are the same.