csplit: panic on overflow in `{N}` repetition count and `/regex/OFF` offset

[leeewee]

Affects: uutils/coreutils main (verified at commit aaf4a353c, 2026-05-28)
Severity: panic + abort on user-supplied input that GNU csplit rejects cleanly

Summary

csplit panics with a Rust backtrace instead of returning a clean error when
the user supplies a pattern argument whose embedded integer exceeds the target
type's range. Two distinct sites in src/uu/csplit/src/patterns.rs call
.unwrap() on a str::parse::<usize>() / str::parse::<i32>():

• line 123 — the {N} repetition count
• line 136 — the /regex/OFF (and %regex%OFF) line offset

Reproduction

$ csplit - 1 '{99999999999999999999999999999999}' < /etc/hostname
thread 'main' panicked at src/uu/csplit/src/patterns.rs:123:83:
called `Result::unwrap()` on an `Err` value: ParseIntError { kind: PosOverflow }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)
$ echo $?
134

$ csplit - '/x/-2147483649' < /etc/hostname
thread 'main' panicked at src/uu/csplit/src/patterns.rs:136:47:
called `Result::unwrap()` on an `Err` value: ParseIntError { kind: NegOverflow }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
Aborted (core dumped)
$ echo $?
134

GNU coreutils 8.30 on the same inputs:

$ /usr/bin/csplit - 1 '{99999999999999999999999999999999}' < /etc/hostname
csplit: '{99999999999999999999999999999999'}: integer required between '{' and '}'
$ echo $?
1

$ /usr/bin/csplit - '/x/-2147483649' < /etc/hostname
csplit: '/x/-2147483649': line number out of range
$ echo $?
1

Offending code

src/uu/csplit/src/patterns.rs

// line 123 — {N} repetition count
if let Some(times) = r.name("TIMES") {
    ExecutePattern::Times(times.as_str().parse::<usize>().unwrap() + 1)
} else { ... }

// line 136 — /regex/OFF offset
let offset = match captures.name("OFFSET") {
    None => 0,
    Some(m) => m.as_str().parse().unwrap(),
};

Both should propagate a CsplitError::InvalidPattern (or a more specific
variant) instead of unwrapping.

Suggested fix

// {N} repetition count
if let Some(times) = r.name("TIMES") {
    let n: usize = times
        .as_str()
        .parse()
        .map_err(|_| CsplitError::InvalidPattern(next_item.to_owned()))?;
    ExecutePattern::Times(n.checked_add(1)
        .ok_or_else(|| CsplitError::InvalidPattern(next_item.to_owned()))?)
} else { ExecutePattern::Always }

// /regex/OFF offset
let offset = match captures.name("OFFSET") {
    None => 0,
    Some(m) => m
        .as_str()
        .parse()
        .map_err(|_| CsplitError::InvalidPattern(arg.to_owned()))?,
};

(The + 1 overflow on usize::MAX does not panic in release builds because
overflow checks are off — but it still produces silently wrong behavior
(Times(0)). The checked_add makes that a clean error in both profiles.)

Found by our static analysis tooling.

[leeewee]

Follow-up: the suggested fix can be tightened so the error output matches GNU
csplit exactly (not just the exit code). Two adjustments:

1. {N} count — use saturating_add(1), not checked_add + error.
   GNU doesn't pre-validate the repetition count against a maximum; it accepts a
   huge N and only fails when the repeated pattern runs past the end of input
   (line number out of range on repetition K). Rejecting N == usize::MAX up
   front diverges from that. Since parse::<usize>() already rejects anything
   > usize::MAX, the + 1 can only overflow at exactly N == usize::MAX, and
   at that magnitude the + 1 is observationally irrelevant (no input has 1.8e19
   lines). Saturating lets the value flow into the existing repetition logic,
   which then produces GNU's exact error.

2. /regex/OFF offset — use CsplitError::LineOutOfRange, not InvalidPattern.
   That variant's message is already byte-identical to GNU's
   '<pattern>': line number out of range.

// {N} repetition count
if let Some(times) = r.name("TIMES") {
    let n: usize = times
        .as_str()
        .parse()
        .map_err(|_| CsplitError::InvalidPattern(next_item.to_owned()))?;
    ExecutePattern::Times(n.saturating_add(1))
} else { ExecutePattern::Always }

// /regex/OFF offset
let offset = match captures.name("OFFSET") {
    None => 0,
    Some(m) => m
        .as_str()
        .parse()
        .map_err(|_| CsplitError::LineOutOfRange(arg.to_owned()))?,
};

With this, uutils matches GNU on every case I tried — exit code, message, and
quoting (verified against GNU coreutils 8.30):

input	uutils (patched)	GNU
{2}	ok, exit 0	ok, exit 0
/b/+1	ok, exit 0	ok, exit 0
{4294967296}	'1': line number out of range on repetition 3	same
{18446744073709551615}	'1': line number out of range on repetition 3	same
/b/-2147483649	'/b/-2147483649': line number out of range	same
/b/+99999999999	'/b/+99999999999': line number out of range	same
abc	'abc': invalid pattern	same

One cosmetic difference remains: for a {N} whose digits exceed usize::MAX
(e.g. {99999999999999999999999999999999}), GNU prints integer required between '{' and '}' with an idiosyncratic quote placement ('{<digits>'} — the
} lands outside the closing quote, because GNU quotes only the substring it
parsed). uutils prints '{<digits>}': invalid pattern. Exit code matches (1);
matching the message exactly would need a dedicated error variant. Happy to
include that if you'd prefer full parity here too.