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 not alter performance

✅ 357 untouched benchmarks
⏩ 50 skipped benchmarks¹

---

_{Comparing AlejandroCoronadoN:fix-truncate-oob-size (c836adb) with main (b2a617e)²}

Footnotes

1. 50 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. ↩

2. No successful run was found on main (0b77ced) during the generation of this report, so b2a617e was used instead as the comparison base. There might be some changes unrelated to this pull request in this report. ↩

[sylvestre]

Please make sure you hr comment shorter

[AlejandroCoronadoN]

Shortened the comment. Thanks!

[github-actions]

GNU testsuite comparison:

Skipping an intermittent issue tests/date/date-locale-hour (passes in this run but fails in the 'main' branch)
Skipping an intermittent issue tests/tail/tail-n0f (passes in this run but fails in the 'main' branch)
Note: The gnu test tests/cut/cut-huge-range is now being skipped but was previously passing.
Congrats! The gnu test tests/rm/many-dir-entries-vs-OOM is now passing!

[AlejandroCoronadoN]

Shortened the comment, thanks.

[cakebaker]

Thanks!

[oech3]

Is it able to move this to clap's value parser?

[cakebaker]

@oech3 the --size input can also contain units, so you would have to write a custom value parser.