truncate: reject a size above i64::MAX instead of creating the file

[AlejandroCoronadoN]

Problem

An absolute size in the range (i64::MAX, u64::MAX] was accepted by the size
calculation and only failed later when opening the file, with a misleading
message, after the file had already been created:

$ truncate -s 8E newfile
truncate: cannot open 'newfile' for writing: out of range integral type conversion attempted
$ ls newfile      # created anyway
newfile

GNU truncate rejects it up front and creates nothing:

$ truncate -s 8E newfile
truncate: Invalid number: '8E': Value too large to be stored in data type

Fix

A file size must fit the signed file offset (i64). Check truncate_size > i64::MAX right after the size is computed and return the existing "invalid
number / value too large" error, before the file is opened.

Verification

Compared against GNU truncate over 8E, 9223372036854775808 (i64::MAX + 1),
9223372036854775807 (i64::MAX), 1E, and 100: exit codes and whether the
file is created now match GNU in every case. Added a regression test; the full
test_truncate suite (49 tests) passes and cargo fmt / cargo clippy are
clean.

[codspeed-hq]

Merging this PR will degrade performance by 3.97%

⚠️ Different runtime environments detected

Some benchmarks with significant performance changes were compared across different runtime environments,
which may affect the accuracy of the results.

Open the report in CodSpeed to investigate

⚡ 2 improved benchmarks
❌ 1 regressed benchmark
✅ 150 untouched benchmarks
⏩ 240 skipped benchmarks¹

Warning

Please fix the performance issues or acknowledge them on CodSpeed.

Performance Changes

	Mode	Benchmark	BASE	HEAD	Efficiency
❌	Simulation	df_with_path	573.7 µs	704.9 µs	-18.62%
⚡	Simulation	du_max_depth_balanced_tree[(6, 4, 10)]	65.2 ms	62.3 ms	+4.54%
⚡	Simulation	du_summarize_balanced_tree[(5, 4, 10)]	16.8 ms	16.1 ms	+4.1%

Tip

Investigate this regression by commenting @codspeedbot fix this regression on this PR, or directly use the CodSpeed MCP with your agent.

---

_{Comparing AlejandroCoronadoN:fix-truncate-oob-size (90f72f2) with main (822aa83)}

Footnotes

1. 240 benchmarks were skipped, so the baseline results were used instead. If they were deleted from the codebase, click here and archive them to remove them from the performance reports. ↩

[sylvestre]

Please make sure you hr comment shorter