split: reject excessive suffix lengths

[wondr-wclabs]

Summary

• reject pathological split -a / --suffix-length values before filename generation
• keep fixed-width suffix numbers from allocating a digit vector during construction
• add regression coverage for the reported large suffix length

Fixes #12599

Notes

I did not inspect GNU coreutils source. The fix is based on the reported behavior and the local uutils failure mode: large suffix lengths could be accepted and then hang/abort while constructing output filenames.

[sylvestre]

the Validation in comment 0 is useless ;)
so, please avoid sending it in the future

[sylvestre]

why 4096 ?

[wondr-wclabs]

I picked 4096 as a conservative allocation guard, not as a semantic suffix limit.

The failure mode here is that split -a <huge> flows into filename construction and can request an absurd allocation before the filename could ever be useful. 4096 is around the common full-path limit on Linux and is already far above typical filename-component limits such as 255 bytes. Since the suffix is appended to the output prefix to form one filename component, values in the thousands are already beyond realistic portable usage, while still keeping the guard loose enough that we do not reject any plausible manual -a value.

So the tradeoff was: make the cap high enough to avoid changing normal behavior, but low enough that pathological inputs cannot allocate attacker-sized strings. If you would rather make the bound stricter and tie it to a component-oriented limit instead, I can switch this to a NAME_MAX-style value such as 255, or rename/comment it more explicitly as an allocation guard.

[sylvestre]

ok - my point was more: it should be documented in the code :)

[wondr-wclabs]

Agreed. I updated the code comment so it explains that 4096 is an allocation guard rather than a semantic suffix limit, and documents the path-limit / filename-component tradeoff directly next to the constant.

That should make the choice reviewable from the code without needing the PR discussion context.

[wondr-wclabs]

Makes sense. The long validation block does not add much in uutils PR openings because CI reruns the important checks and the extra command list makes the review thread harder to scan.

I have removed it from this PR and will keep future uutils PR descriptions focused on the behavior change and rationale. I will only call out local validation when it explains a review question, a failing check, or a CI discrepancy.

[github-actions]

GNU testsuite comparison:

Skip an intermittent issue tests/date/date-locale-hour (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/misc/tty-eof (fails in this run but passes in the 'main' branch)
Skip an intermittent issue tests/tail/retry (fails in this run but passes in the 'main' branch)
Note: The gnu test tests/cp/link-heap is now being skipped but was previously passing.

[wondr-wclabs]

I checked the remaining red Code Coverage (ubuntu-latest, unix) job. It does not appear related to this split change: the failing test is test_mkfifo::test_create_one_fifo_already_exists, and the log also shows an LLVM profile write error:

LLVM Profile Error: Failed to write file ".../coverage/traces/...profraw": Permission denied

The split-specific checks and GNU comparison are green, including the bounded-memory improvement. I tried to rerun the failed job, but GitHub rejected it because I do not have repository admin rights for reruns. I am leaving the branch unchanged rather than patching unrelated mkfifo/coverage behavior from this PR.