Skip to content

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

Open
AlejandroCoronadoN wants to merge 1 commit into
uutils:mainfrom
AlejandroCoronadoN:fix-truncate-oob-size
Open

truncate: reject a size above i64::MAX instead of creating the file#13902
AlejandroCoronadoN wants to merge 1 commit into
uutils:mainfrom
AlejandroCoronadoN:fix-truncate-oob-size

Conversation

@AlejandroCoronadoN

Copy link
Copy Markdown

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.

An absolute size that fits in u64 but exceeds i64::MAX (for example `-s 8E`)
passed the size calculation and was only rejected later, when opening the file,
with a misleading "out of range integral type conversion" error, after the file
had already been created. GNU reports an invalid number up front and does not
create the file. Check the size against i64::MAX before opening, reusing the
existing "value too large" message.
@codspeed-hq

codspeed-hq Bot commented Aug 13, 2026

Copy link
Copy Markdown

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 benchmarks1

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)

Open in CodSpeed

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant