GeezerVison

--width is parsed with a regex that is missing the ^ anchor its --tabsize neighbour has one line above it, so it matches any argument whose lossy form ends in --width=<digits> rather than the option itself.

That produces two symptoms, and the quieter one is worse than the reported crash:

$ printf 'a\nb\nc\n' > A; printf 'a\nX\nc\n' > B

$ diff $'\xff--width=5' A B
thread 'main' panicked at src/params.rs:116:45:
called `Result::unwrap()` on an `Err` value: "\xFF--width=5"
$ echo $?
134

$ diff xx--width=5 A B
2c2
< b
---
> X
$ echo $?
1

The first is the abort from the issue: a non-UTF-8 argument reaches into_string().unwrap() and, under panic = "abort", takes the process down. The second does not crash at all. xx--width=5 is accepted as a width, the operand is quietly discarded, and diff compares the two files that are left. GNU treats both as file operands and exits 2 with extra operand 'B'.

The fix

Anchoring the regex restores the invariant the --tabsize block documents a little further down, that a match implies valid UTF-8. I added that same comment to the --width block and left the existing unwrap in place rather than reworking it separately, so the two option paths keep reading the same way. To be precise about what this does: the anchor makes that unwrap unreachable, it does not remove it.

Tests

--width had no test coverage, which is how this survived. There is now a width test next to tabsize, covering valid values and the same invalid forms tabsize already checks, plus both cases above. The non-UTF-8 case is cfg(unix), since it needs bytes an OsString cannot hold on Windows.

Both new assertions fail without the anchor: width_non_utf8_operand aborts at into_string().unwrap(), and width fails on xx--width=5.

Verification

Exit codes compared against GNU diffutils 3.12:

cargo test goes from 272 to 274 passing, and cargo fmt --all -- --check, cargo clippy -- -D warnings and cargo test --all-features --no-fail-fast are clean. The GNU upstream test suite gives identical per-test results before and after. I ran it on macOS, where much of it fails for unrelated environment reasons, so I compared per test against a clean main build rather than reading the totals.

Out of scope

The error text still differs from GNU here: this prints Usage: diff <from> <to> where GNU prints extra operand 'B' followed by a Try --help line. That is not specific to --width, it happens for any three-operand invocation, so I left it alone.

Closes #247