MINOR: [C++][Compute] Avoid signed overflow in slice kernel output sizing

[Nayana-Naik73]

Rationale for this change

SliceBytesTransform::MaxCodeunits (binary_slice) and SliceCodeunitsTransform::MaxCodeunits (utf8_slice_codeunits) size the output buffer from (stop - start + step - 1) / step using raw int64_t arithmetic on the user-supplied SliceOptions, whose start, stop and step are unbounded. A large stop (binary) or a large step/very negative start (utf8, where only stop is clamped) overflows the addition/subtraction, so max_slice_bytes wraps negative, std::max<int64_t>(0, .) collapses it to 0, and the kernel allocates a zero-length output buffer. Transform then writes the real slice into that buffer, an out-of-bounds write.

This is reachable from a default pyarrow call: pc.binary_slice(arr, 0, step=2) leaves stop at sys.maxsize (INT64_MAX), so stop - start + step - 1 is INT64_MAX + 1. Under a UBSan build the subtraction/addition is flagged as signed-integer-overflow; under ASan the subsequent copy is a heap-buffer-overflow.

scalar_string_ascii.cc:2645:53: runtime error: signed integer overflow:
  9223372036854775807 + 2 cannot be represented in type 'int64_t'

What changes are included in this PR?

Both MaxCodeunits overrides compute the span and the final ninputs * estimate product with SubtractWithOverflow/AddWithOverflow/MultiplyWithOverflow and fall back to the input length on overflow. The input length is always a valid upper bound on the sliced output, so this matches the existing mismatched-sign fallback and leaves the value bit-identical for every non-overflowing input.

Are these changes tested?

Yes. SliceBytesOverflow and SliceCodeunitsOverflow in scalar_string_test.cc exercise INT64_MAX/INT64_MIN options (including the default pyarrow stop). They abort under UBSan/ASan on the current tree and pass with the fix; the full arrow-compute-scalar-type-test suite stays green (352 tests).

Are there any user-facing changes?

No. Valid inputs produce the same results; only the pathological overflow case now allocates the safe worst-case buffer instead of corrupting memory.

This PR contains a "Critical Fix". An overflow in the slice output-size computation led to a zero-length allocation followed by an out-of-bounds write of the sliced bytes.

Was AI used for this PR?

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

[github-actions]

Thanks for opening a pull request!

This pull request has been automatically closed because you currently have 4 open pull requests, which is more than the limit of 3.

Due to the increase in pull requests opened by AI bots, and in order to keep the review queue manageable, Apache Arrow limits contributors without repository access to at most 3 concurrently open pull requests. This helps make sure each pull request gets the attention it needs and that work in progress does not go stale.

Once one of your other open pull requests has been merged or closed, you are welcome to reopen this one.

See also:

• Contribution Guidelines - Limit on concurrent pull requests
• Contribution Guidelines - Contributing Overview