printf/seq still panic on large float precision and field width after #12572 integer-precision fix

Version

uutils/coreutils HEAD c61b8813 tested on 2026-06-07.

Summary

The integer-precision panic from #12572 was fixed by commit 452824f8a, but related float-precision and field-width paths still abort the process with SIGABRT / exit 134. This is not a security advisory; it is a normal correctness/DoS issue because the oversized width/precision is invoker-supplied and does not cross a privilege, memory, authentication, or data boundary.

Reproduction

printf '%.70000f' 1
printf '%#.70000g' 0
printf '%.70000a' 0
printf '%70000d' 1
printf '%500000s' x
seq -f '%.70000f' 1 1

Observed uutils result: panic / exit 134. GNU printf and GNU seq exit 0 for the same cases.

Boundary observations:

%65535d      ok
%65536d      panic
%1000000d    panic
%1000001d    caught / exits 1

This suggests the width guard threshold is too high for the internal formatting path: it uses 1_000_000, while the internal sink fails above u16::MAX in several cases.

Non-affected controls:

%.Ne / %.Ng / %.Na on non-zero values: no panic
stat --printf="%70000s": exits 1, not panic
Impact

Local process abort from invoker-supplied arguments. This is a normal issue, not a GHSA.

Suggested fix

Apply a consistent width/precision bound before the affected formatting sinks, or avoid formatting paths that panic above u16::MAX.

Start by running the listed printf and seq reproductions and compare their exit statuses with GNU printf and seq. Trace the affected float-precision and field-width formatting paths, focusing on the 1,000,000 guard and the u16::MAX boundary. Done means oversized inputs no longer panic or abort, while the affected commands return controlled results.