Fix overflows of untyped int constants on 32-bit

[dswarbrick]

9223372036 as an untyped int constant will overflow on 32-bit archs.

math.MaxInt64 is an untyped int constant (1<<63 - 1), and will thus also overflow on 32-bit if not cast to an int64.

Refs: #654

[dswarbrick]

Fixes test build failures on 32-bit:

# github.com/prometheus/common/helpers/templates [github.com/prometheus/common/helpers/templates.test]
helpers/templates/time_test.go:92:27: cannot use 9223372036 (untyped int constant) as int value in struct literal (overflows)
helpers/templates/time_test.go:121:30: cannot use math.MaxInt64 (untyped int constant 9223372036854775807) as int value in argument to HumanizeTimestamp (overflows)
FAIL    github.com/prometheus/common/helpers/templates [build failed]

Please consider adding a 32-bit test (i.e. with GOARCH=386) to your CI pipeline. These 32-bit overflows sneak into the code again and again, and it really ought to be trivial to prevent that.

[beorn7]

Thank you.

[beorn7]

I guess the tests on prometheus/prometheus run for so long that we got a bit reluctant adding more platforms. I'll put this on the dev-summit agenda to make a call.

[dswarbrick]

Perhaps make more judicious use of the -short test flag and skip lengthy tests.

Or something like GOARCH=386 go test -run NonexistentTestName ./..., so that Go would attempt to compile all code, but not actually run any tests. That at least would catch these 32-bit build failures.

[beorn7]

Definitely points to consider for the discussion (which I would love to have at the dev summit, because it affects all Go repositories).

I think the 32-bit case is similar to the MS Windows case (for which we do run tests), i.e. maybe there aren't that many users, but at the very least we don't want to bother people with portability errors that are easily caught be tests or the compiler.