fix: reject out-of-range integral cell values

[nkuprins]

Closed: #1100

Purpose of the pull request

As title.

What's changed?

• Integer converters and NumberUtils.parseByte/parseShort/parseInteger/parseLong now range-check the value before narrowing, so out-of-range values throw instead of wrapping around.
• The integer parse* methods now call parseBigDecimal, which already has the hasFormat branch.
• Added out-of-range tests to ConverterTest and NumberUtilsTest.

Checklist

• I have read the Contributor Guide.
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

[skytin1004]

Thanks for the fix. I reproduced the issue on main and verified the fix for XLSX, XLS, and CSV. LGTM.

[BigDataDZ]

Reviewed the diff - the approach looks right: checkRange truncates toward zero first (so fractional values keep narrowing the way they did before intValueExact-style strictness would allow) and only the truncated integral part is range-checked, which matches the semantics I had implemented in the now-closed #1188.

One suggestion: add a fraction-truncation regression test (e.g. parseInteger("123.9") == 123 and the same for a NUMBER cell on IntegerNumberConverter). Nothing in the current tests pins that behavior, and it protects the narrowing semantics from being "exactified" by a future refactor.

[nkuprins]

Reviewed the diff - the approach looks right: checkRange truncates toward zero first (so fractional values keep narrowing the way they did before intValueExact-style strictness would allow) and only the truncated integral part is range-checked, which matches the semantics I had implemented in the now-closed #1188.

One suggestion: add a fraction-truncation regression test (e.g. parseInteger("123.9") == 123 and the same for a NUMBER cell on IntegerNumberConverter). Nothing in the current tests pins that behavior, and it protects the narrowing semantics from being "exactified" by a future refactor.

Thanks, the fraction case is already pinned: test_parseInteger_noFormat_truncatesFraction and the 42.9 assertion in ConverterTest cover it, and test_toInt_bounds covers the 2147483647.9 / -2147483648.9 boundary that a stricter refactor would break. I'd rather not add a near-duplicate 123.9 test.

[delei]

LGTM. The range checks make the parsing behavior much safer and more predictable.