m-lab / ndt-server / 443 / 1
59%
main: 76%

LAST BUILD BRANCH: dependabot/go_modules/cmd/generate-schemas/golang.org/x/oauth2-0.27.0
DEFAULT BRANCH: main
Ran
Files 19
Run time 4s
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 58.844%. First build
443.1

push

travis-ci

bassosimone 
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.)

692 of 1176 relevant lines covered (58.84%)

0.63 hits per line

Source Files on job 443.1