Description
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version
)?
go version go1.10.3 darwin/amd64
golang.org/x/mobile
commit bceb7ef27cc623473a5b664d2a3450576dddff0f
Does this issue reproduce with the latest release?
Yep
What operating system and processor architecture are you using (go env
)?
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/verm/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/verm/remix/turntable/amp"
GORACE=""
GOROOT="/usr/local/Cellar/go/1.10.3/libexec"
GOTMPDIR=""
GOTOOLDIR="/usr/local/Cellar/go/1.10.3/libexec/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
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"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/36/92jbhtpj41s6q3w4fcq2v01w0000gn/T/go-build566537997=/tmp/go-build -gno-record-gcc-switches -fno-common"
What did you do?
I had a function that needed to take a timeout, which internally is a time.Duration
(int64
). That's not a type I can use in the mobile bindings, so I used an int
parameter. This gets translated as a long
in Objective-C. My Obj-C code took an int64_t
value and passed it as the long parameter of the wrapped Go function.
I then passed an Obj-C int64_t
value that doesn't fit in a 32-bit int to this function.
What did you expect to see?
I would expect that Go would see the original 64-bit value unaffected.
What did you see instead?
Surprisingly, is that even though long
(in Obj-C) and int
(in Go) are 64-bit types on these platform (Mac OS X 10.13.6 / iOS simulator and iPhone 7 running iOS 11.4), the result in Go was an int
holding the lower 32 bits of the original value. Specifically, for an input of int64_t x = 86400000000000
, the value of the int
passed to the Go function was -1857093632
.
In this particular case, the correct choice in retrospect was clearly to use int64
as the parameter type in Go. This results in a wrapper type in Objective-C of int64_t
, and everything works fine.
But I am still surprised that int
would behave in this way on a 64-bit system.