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.
The text was updated successfully, but these errors were encountered:
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?golang.org/x/mobile
commitbceb7ef27cc623473a5b664d2a3450576dddff0f
Does this issue reproduce with the latest release?
Yep
What operating system and processor architecture are you using (
go env
)?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 anint
parameter. This gets translated as along
in Objective-C. My Obj-C code took anint64_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) andint
(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 anint
holding the lower 32 bits of the original value. Specifically, for an input ofint64_t x = 86400000000000
, the value of theint
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 ofint64_t
, and everything works fine.But I am still surprised that
int
would behave in this way on a 64-bit system.The text was updated successfully, but these errors were encountered: