fix: csplit --suffix-format huge field width panics instead of erroring#13256
fix: csplit --suffix-format huge field width panics instead of erroring#13256mvanhorn wants to merge 1 commit into
Conversation
Merging this PR will not alter performance
Comparing Footnotes
|
|
GNU testsuite comparison: |
|
sorry but could you please rebase it ? thanks |
d65969e to
24b9c6a
Compare
|
Rebased onto main. There were a couple of real conflicts from the csplit error-type refactor (the new |
Summary
csplitno longer panics when--suffix-formatrequests an enormous field width. A format like--suffix-format=%0999999999dnow returns a clean error instead of aborting with a Rust panic, because the split-name formatter propagates the formatting error rather than unwrapping it.Why this matters
Issue #12763 reports that
csplitpanics on a--suffix-formatwith a very large field width.SplitName::getusedwrite!/format!and unwrapped the result; for a pathological width the formatter allocation/formatting failed and the unwrap turned that into a panic, crashing the utility instead of reporting a usage error the way GNUcsplitdoes.The formatter now returns
io::Result<String>and the caller surfaces a propercspliterror, so an unusable suffix format is rejected with a message and a non-zero exit rather than a panic.Testing
cargo test -p uu_csplitpasses, including a newtest_csplitcase asserting that a huge--suffix-formatwidth errors out (non-zero exit, no panic) instead of crashing.cargo clippy -p uu_csplitis clean.Fixes #12763