fix: do the formatting length arithmetic in long

[matt-edmondson]

Fixes #75

Problem

ToString and TryFormat sized their buffers with int arithmetic over the exponent, so a value whose exponent sat near either end of the int range threw instead of formatting. Parse accepts any exponent an int holds, so a value could parse successfully and then fail to format.

Value	ToString() before	ToString() after	TryFormat into 64 chars before	after
1E-2147483648	OverflowException (from int.Abs)	OverflowException naming the exponent	ArgumentOutOfRangeException	false
1E2147483647	ArgumentOutOfRangeException	OverflowException naming the exponent	ArgumentOutOfRangeException	false

Changes

• ToString sizes its buffer in long, and throws an OverflowException naming the exponent when the fixed point text could not exist as a string at all, rather than surfacing the failure as a negation or allocation error.
• TryWriteDigits (behind TryFormat) does every length in long, so the comparison against the destination's length is what answers. It now returns false for any destination too small, whatever the exponent, instead of wrapping a length negative and reaching Span.Slice.
• CountDecimalDigits returns long. An exponent of int.MinValue implies 2,147,483,648 decimal digits, one more than an int can count, and int.Abs(int.MinValue) throws. LowestDecimalDigits follows it.
• Round follows the widened count, and stops raising ten to a power wider than the significand: dropping one digit more than the significand holds always leaves zero, so a value far below the requested place now rounds to zero instead of throwing.

This is the same treatment #72 gave the conversion paths, applied to formatting.

Deliberately not changed

Formatting stays fixed point, so 1E-1000000 still renders as 1,000,002 characters. Switching to scientific notation past some exponent, or supporting the "E" format string, is a separate API decision — "G" is the only format accepted today and changing what it means would change existing output. Left to #75 to decide.

Testing

Six tests added in PreciseNumberTests.cs, covering int.MinValue and int.MaxValue exponents across ToString, TryFormat, CountDecimalDigits and Round, plus the parse-then-format path from the issue's repro and a regression guard at large-but-representable exponents (1E±1000).

• Five of the six fail against main and pass with the fix — verified by reverting PreciseNumber.cs alone and re-running. The sixth is the regression guard, which passes either way.
• Full suite: 266 passed, 0 failed.
• Solution builds clean across net7.0/8.0/9.0/10.0 with no new warnings.
• TextBenchmarks run before and after (--job short, Digits 8/30/200): means unchanged within noise, allocations byte for byte identical.

No public API signature changes; the behaviour changes are all in cases that previously threw.

🤖 Generated with Claude Code

https://claude.ai/code/session_01XbHTU3pZh6egvtowTyuqNM

---

Generated by Claude Code

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
100.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud