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.