Latest Results
diff: don't panic on an operand ending in --width=N
The `--width` regex was missing the `^` anchor that its `--tabsize` sibling
one line above already has, so it matched any argument whose lossy form ended
in `--width=<digits>` rather than the option itself. Two symptoms follow, and
the quieter one is worse:
diff $'\xff--width=5' A B # aborts, exit 134
diff xx--width=5 A B # taken as a width, the operand is discarded
The first reaches `into_string().unwrap()` with a non-UTF-8 argument and, under
`panic = "abort"`, takes the process down. The second does not crash at all: the
operand is swallowed as a width and diff compares the remaining two files,
exiting 1. GNU treats both as file operands, reports the extra operand, exits 2.
Anchoring restores the invariant the `--tabsize` block documents, that a match
implies valid UTF-8, so the existing `unwrap` is sound rather than merely
unlikely to fire. I mirrored that block rather than reworking the `unwrap`
separately, to keep the two option paths reading the same way.
`--width` had no test coverage, which is how this survived. Added a `width` test
alongside `tabsize` covering valid values and the invalid forms, plus both cases
above. The non-UTF-8 one is `cfg(unix)`, since it needs bytes an `OsString`
cannot hold on Windows.
Exit codes now match GNU diffutils 3.12 for `--width=5`, `--width=5x`,
`xx--width=5` and the non-UTF-8 form. The error text still differs, because uu
prints its usage line where GNU names the extra operand, but that gap predates
this change and affects any three-operand invocation.
Closes #247ARMeeru:fix/anchor-width-option-regex Latest Branches
0%
renovate/major-github-artifact-actions 0%
renovate/actions-checkout-7.x 0%
© 2026 CodSpeed Technology