zeroshade commented on code in PR #1219:
URL: https://github.com/apache/arrow-go/pull/1219#discussion_r3883854390
##########
arrow/array/concat.go:
##########
@@ -861,37 +861,44 @@ func updateRuns[T int16 | int32 | int64](inputData
[]arrow.ArrayData, inputBuffe
// can fold the end and beginning of each array we're concatenating
// into a single run
pos := 0
+ logicalLen := T(0)
for i, buf := range inputBuffers {
if buf.Len() == 0 {
continue
}
src := arrow.GetData[T](buf.Bytes())
+ logicalLen += T(inputData[i].Len())
if pos == 0 {
pos += copy(output, src)
// normalize the first run ends by subtracting the
offset
for j := 0; j < pos; j++ {
output[j] -= T(inputData[i].Offset())
}
+ } else {
+ lastEnd := output[pos-1]
+ // we can check the last runEnd in the src and add it
to the
+ // last value that we're adjusting them all by to see
if we
+ // are going to overflow
+ if
uint64(lastEnd)+uint64(int(src[len(src)-1])-inputData[i].Offset()) >
uint64(maxOf[T]()) {
Review Comment:
The overflow check still uses the slice’s physical final run end before the
new logical-length clamp. This rejects valid near-limit inputs. A valid `int16`
REE prefix of length 32,760 followed by a one-element slice of a physical
32,767-element run should produce length 32,761, but currently returns
`invalid: overflow in run-length-encoded run ends concat`. Please clamp the
normalized final source end to the sliced input’s logical length before both
the overflow check and output write, and add this boundary regression test.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
