m-lab / ndt-server / 444

59%

main: 76%

Pull #71

travis-ci

Do not use float64 when int64 would suffice

It makes sense to use float64 where the measurement unit is
a floating, but using it when we're sending integer quantities
is actually a bit surprising.

While it's true that `float64` is native to the i386 platform
and `int64` it's not, I don't even know whether `int64` is slower
than `float64` and, even if that was the case, it would probably
be weird anyway to use `float64` rather than `int64`.

Another reason why I was using `float64` is that I didn't know
how to extact `int64`s from C code. But C code is gone in the
previous commit. Conclusion: let's use `int64` instead.

Now, why `int64` and not `uint64`? The different is subtle. We
know that in many cases golang is using signed integers also
for sizes, so that is not so surprising in golang. In Java there
is no unsigned, so in theory I could say I am doing this for
the sake of good old Java. The reality is that JSON cannot really
serialize numbers larger than 2^53 as integers, therefore the
distinction betwwn `int64` and `uint64` here is academic. Thus,
I have picked the most natural feat in golang.

(Should I check for overflow? In theory. In practice I think we
are good for quite some years without checking for overflow of
`int64` variables. Also, in the server side there are checks for
overflow of `int64`, but not of `int53`. In the client side I
think we should not care, since that is a minimal client.)

6 of 6 new or added lines in 2 files covered. (100.0%)

692 of 1176 relevant lines covered (58.84%)

0.63 hits per line