Go: math: MaxInt64 overflows int on ARM

Created on 11 Dec 2017  ·  11Comments  ·  Source: golang/go

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.9.2 linux/arm

Does this issue reproduce with the latest release?

Yes

What operating system and processor architecture are you using (go env)?

GOARCH="arm"
GOBIN=""
GOEXE=""
GOHOSTARCH="arm"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/alarm/go"
GORACE=""
GOROOT="/usr/local/go1.9.2.linux-armv6l"
GOTOOLDIR="/usr/local/go1.9.2.linux-armv6l/pkg/tool/linux_arm"
GCCGO="gccgo"
GOARM="6"
CC="gcc"
GOGCCFLAGS="-fPIC -marm -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build788013818=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"

What did you do?

Here is a minimum working example of the error.

package main

import (
    "math"
)

func main() {
    min := math.MaxInt64
}

What did you expect to see?

This program should generate no errors. (actually it complains that min is declared and not used, but that's not important right now)

What did you see instead?

# command-line-arguments
./mwe.go:8:6: constant 9223372036854775807 overflows int
FrozenDueToAge

Most helpful comment

min := int64(math.MaxInt64)

All 11 comments

I have just learned that armv7l is 32-bit so of course int would be 32 bits wide and overflowing is understandable.

After a discussion on the Slack community, I have learned that the current behavior is part of the specification. Kale Blankenship helpfully cited the specific section: https://golang.org/ref/spec#Constants. This section says the default type for this constant would be int which is what's happening. I'm going to close this issue as works-as-expected.

I was just typing up the same response and here is a duplicate issue that was closed https://github.com/golang/go/issues/19621. Thank you for the find and for closing the issue.

@ianlancetaylor @robpike do you think this qualifies as a candidate for a doc/faq entry? I ask because I've encountered this before and the internet helped me with the fix, someone else in #19621 did and so has @mathuin right now, who knows who else.

I'm not sure it quite qualifies as a FAQ. It's more like a bug that we can't fix because of the Go 1 compatibility guarantee. I think the best resolution would be to use explicit types in Go 2, though I don't see a proposal open for that.

Gotcha @ianlancetaylor, thank you for the advice. I'd open the bug/proposal but I wouldn't have as much substance or context as you would have, so feel free to go ahead and open one, if you please. However, I'd be delighted to contribute to it i.e. working on a fix or helping out,

Filed #23087.

Awesome, thank you @ianlancetaylor!

I do understand that it is by the spec, but can you please provide an workaround snippet on how to overcome this?

min := int64(math.MaxInt64)

Thanks. Helped a lot.

Was this page helpful?
0 / 5 - 0 ratings