GH-50544: [C++][Gandiva] fix out-of-bounds read in round with most negative precision

[Arawoof06]

Rationale for this change

round_int32_int32 and round_int64_int32 negate the caller-supplied precision into abs_precision before range-checking it, so the check abs_precision > 9 (and > 18 for the int64 overload) never fires for precision == INT32_MIN, where the negation leaves the value negative. That value reaches get_power_of_10, which indexes a 19-element static table behind DCHECK_GE/DCHECK_LE only. The DCHECKs compile out in release builds, so round(int_col, -2147483648) reads far outside the table and either faults or returns arbitrary memory as the rounding multiplier. Both overloads are registered in function_registry_arithmetic.cc, so the precision comes straight from user SQL.

truncate_int64_int32 in the same file already compares the signed scale directly (out_scale < -38) and is unaffected; the two round overloads are the only sites that negate first.

What changes are included in this PR?

Check the bound against the signed precision before negating, at both sites. Every precision that was in range before still takes the same path, and the negation now only runs on values known to be within 9 (or 18) of zero.

Are these changes tested?

Yes. Added two cases to TestExtendedMathOps.TestRound covering std::numeric_limits<int32_t>::min() for both overloads, matching the existing truncate_int64_int32 case in the same file. On the unpatched tree the debug build aborts with extended_math_ops.cc:372: Check failed: (exp) >= (0); with the fix the full gandiva-precompiled-test suite passes (134 tests).

Are there any user-facing changes?

No.

This PR contains a "Critical Fix". It fixes an out-of-bounds read reachable from a user-supplied round precision argument.

• GitHub Issue: [C++][Gandiva] Out-of-bounds read in round(int, precision) for the most negative precision #50544

[github-actions]

⚠️ GitHub issue #50544 has been automatically assigned in GitHub to PR creator.

[github-actions]

⚠️ GitHub issue #50544 has no components, please add labels for components.

[Reranko05]

Would it make sense to also add tests for the -9/-10 boundary (and -18/-19 for the int64 overload)? They could help catch any future off-by-one regressions around the new range check.

[Arawoof06]

Good idea, added them. There's now a -9/-10 pair for the int32 overload and -18/-19 for the int64 one, so the last in-range precision still rounds and one past it returns 0. That pins the boundary against any future off-by-one.

[Arawoof06]

Rebased onto current main. The earlier macOS failures were the aws-sdk s3fs crash on the July base, unrelated to this change. On the rebased run gandiva-precompiled-test passes everywhere; the three macOS jobs still red are an arrow-s3fs-test timeout, an acero hash-join timeout and a MinIO download DNS error on the runners.