fix util_tests.cpp clang warnings #6241

was introduced with #6121.

Fixes two warnings:

test/util_tests.cpp:353:64: warning: integer literal is too large to be represented in a signed integer type, interpreting as unsigned [-Wimplicitly-unsigned-literal]
    BOOST_CHECK(ParseInt64("-9223372036854775808", &n) && n == 9223372036854775808LL);

test/util_tests.cpp:353:61: warning: comparison of integers of different signs: 'int64_t' (aka 'long long') and 'unsigned long long' [-Wsign-compare]
    BOOST_CHECK(ParseInt64("-9223372036854775808", &n) && n == 9223372036854775808LL);

I don't get it. Why do you need unsigned integer here? If these are truly outside the 64 bit signed integer range, these tests should not be passing. As I understand it, the range of int64_t should be -2^63 to 2^63-1, or .-9223372036854775808 to 9223372036854775807. These are the limits that I'm testing. Am I mistaken?

I really had my brain in "off mode" when i was writing this PR. I just added the same changes clang did warn about. Now i have changed it from 9223372036854775807L to (int64_t)9223372036854775807 which should be the same IMO. Fixed also the - sign in front of the min check (-9223372036854775808).

Still get a warning: But it looks like that there is a bug in clang, because: (int64_t)-9223372036854775808 -> shows warning (...is too large to be represented in a signed integer type...) (int64_t)-9223372036854775807 -> OK This is definitively wrong somehow.

I believe you need to use (int64_t)-9223372036854775807-1, otherwise it tries to negate 9223372036854775808, which itself doesn't fit to be negated.

*_MIN are usually defined that way, anyway:

#   define LLONG_MIN    (-LLONG_MAX - 1LL)

I believe you need to use (int64_t)-9223372036854775807-1, otherwise it tries to negate 9223372036854775808, which itself doesn't fit to be negated.

-9223372036854775807LL-1LL, then. I don't think you need the cast.

So I'm starting to understand. The C compiler itself uses 64 bit integers internally, and it parses the token '9223372036854775808' not -9223372036854775808. The value then overflows while parsing, in the end there's no difference but it likes to warn about it.

That means there is no way to represent the smallest integer without doing arithmetic, that's kind of stupid. But ok, fine with shutting up this warning, I just don't want another issue about this where it causes a warning in yet another compiler.

@theuni Okay. I see and understand this now better. Thanks. Changed PR the follow the arithmetical way.

utACK

Ok, thanks, it passes travis. Going to merge this. If there is another compiler that starts to complain about that line we're just going to ignore it. We're writing software for users, not to make compilers happy.