GH-34784: [Go] Fix 32-bit build #35767
Conversation
|
@raulcd @assignUser would it be okay to get this into the v12.0.1 patch release? |
|
|
github-actions
bot
added
Component: Go
awaiting committer review
github-actions
bot
added
awaiting merge
|
@lidavidm only in the spots where it's possible we might be dealing with values that will actually go near the overflow/underflow boundaries. I think it's fine to play wack-a-mole with them when users find issues for now as it doesn't come up often and as long as new code is developed properly. |
|
Yup - I don't think we need to change everything immediately |
This seems to be an atomic change with no links to other commits and it fixes an important issue for 32bit users so +1 from me. |
|
Thanks @assignUser I'll merge this and have it marked as milestone 12.0.1 |
### Rationale for this change Two locations in the code cause issues when building with `GOARCH=386` (e.g. 32-bit systems). ### What changes are included in this PR? In the `compute` package we assume a 64-bit system when using an untyped `int` to hold `math.MaxInt64` which overflows on a 32-bit system. So we just explicitly identify it as an `int64` In the `cdata` package we use the older `*(*[maxlen]*C.void)(unsafe.Pointer(.....))[:]` syntax to retrieve the `void**` for the buffers, with maxlen set to a very large constant. Unfortunately on a 32-bit system this is larger than the address space. Instead we switch to using the `unsafe.Slice` method that was added in go1.17. * Closes: #34784 Authored-by: Matt Topol <zotthewizard@gmail.com> Signed-off-by: Matt Topol <zotthewizard@gmail.com>
|
Benchmark runs are scheduled for baseline = 77a7130 and contender = 9eaee2a. 9eaee2a is a master commit associated with this PR. Results will be available as each benchmark for each run completes. |
|
['Python', 'R'] benchmarks have high level of regressions. |
Rationale for this change
Two locations in the code cause issues when building with
GOARCH=386(e.g. 32-bit systems).What changes are included in this PR?
In the
computepackage we assume a 64-bit system when using an untypedintto holdmath.MaxInt64which overflows on a 32-bit system. So we just explicitly identify it as anint64In the
cdatapackage we use the older*(*[maxlen]*C.void)(unsafe.Pointer(.....))[:]syntax to retrieve thevoid**for the buffers, with maxlen set to a very large constant. Unfortunately on a 32-bit system this is larger than the address space. Instead we switch to using theunsafe.Slicemethod that was added in go1.17.