GH-50275: [C++][CSV] avoid int32 overflow in block parser value counts

[metsw24-max]

Rationale for this change

The CSV block parser sizes its per-chunk value array from num_cols, the column count inferred from the first line of the input, times the rows-in-chunk count. PresizedValueDescWriter computes 2 + num_rows * num_cols, and ParseSpecialized computes num_cols_ * (num_rows_ - start) * 10, both in int32_t. A CSV whose first line carries a few million fields pushes these products past INT32_MAX, which is signed-integer-overflow UB (UBSan flags both expressions).

What changes are included in this PR?

Raise an error if the num_cols would prevent the block size from fitting in a 32 bits integer.

Are these changes tested?

With a new unit test.

Are there any user-facing changes?

No.

• GitHub Issue: [C++][CSV] Possible int32 overflow of per-chunk value count in block parser #50275

[metsw24-max]

Pushed a clang-format fix for the C++ Format lint failure. The macOS Python job looks like an unrelated teardown issue, not from this change.

[pitrou]

ParsedValueDesc stores a 32-bit offset, so we'll be having a problem anyway, right?
How about we simply error out when the product of rows and columns is greater than 2**31?

[metsw24-max]

Good point, the offset is only 31 bits so widening the products doesn't actually save us once the value count passes int32. I've switched to erroring out before presizing when rows x cols would exceed INT32_MAX, and added a test that drives num_cols high enough to trip it. Kept the two multiplications in int64 as well, since the capacity's +2 and the bulk-filter threshold's * 10 can still overflow within that limit.

[pitrou]

@metsw24-max Thanks for the update! This is looking good, but can you open an issue for this? This is not a MINOR issue.

[github-actions]

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

[metsw24-max]

Opened #50275 and re-titled the PR to reference it. Cheers.

[pitrou]

CI failures are unrelated, I'll merge.

[conbench-apache-arrow]

After merging your PR, Conbench analyzed the 4 benchmarking runs that have been run so far on merge-commit d8890e0.

There was 1 benchmark result indicating a performance regression:

• Commit Run on amd64-m5-4xlarge-linux at 2026-06-29 19:44:46Z
  • file-write (Python) with compression=uncompressed, dataset=fanniemae_2016Q4, file_type=feather, input_type=table

The full Conbench report has more details.