[matt-edmondson]

Fixes #178

What was wrong

Parse read the exponent text as an int and then ran checked(exponent - decimalDigits). That subtraction counted every written fraction digit, padding zeros included, and it happened before the value was normalized. So:

• "2.500E-2147483647" and "1.0e-2147483648" threw OverflowException, even though 25e-2147483648 and 1e-2147483648 are representable.
• ToString("E") output for values near int.MinValue could not be parsed back. At those magnitudes "E" is the only text form that fits in a string, so this broke round-tripping.
• "0e99999999999" threw. decimal and double both return 0 for it.

The fix

The tail of Parse moves into a new FromParsedParts helper. The move keeps Parse under the CA1502 complexity limit. The helper:

• drops trailing zeros from the collected digits before applying the exponent
• reads the exponent as a long, applies the fraction and trailing-zero adjustments in checked long arithmetic, and throws OverflowException only if the final exponent falls outside int
• returns Zero when every digit is zero, whatever the exponent says, including one too large for long. A malformed exponent ("0e", "0ex", "0e 5") still throws FormatException.

TryParse still reports a genuine overflow as false.

Tests

The new tests are in a new file, PreciseNumberParseExponentTests.cs:

• Parse_AppliesTheExponentAfterDroppingPaddingZeros covers each input from the issue, plus negative and near-int.MaxValue cases, through both Parse and TryParse.
• Parse_ReadsZeroWhateverItsWrittenExponent checks, for each input, that decimal returns 0 and that PreciseNumber returns Zero.
• Parse_StillOverflowsForAValueOutsideTheExponentRange checks that genuine overflow still throws, or returns false from TryParse.
• Parse_RejectsAMalformedExponentEvenOnZero
• Parse_RoundTripsScientificTextAtTheEdgesOfTheExponentRange covers Parse(x.ToString("E")) for exponents within 10 of int.MinValue and int.MaxValue, which is the issue's acceptance criterion.

Results:

• Without the fix, 9 of the new cases fail. With it, all pass.
• The full suite passes: 536/536. The solution builds for every target framework with no warnings or analyzer findings.
• I did not run the benchmarks. On the normal path the only addition is a backwards scan over trailing '0' characters that were already collected.

Open PR #176 also edits Parse, for NBSP separators, and PR #179 (#177) adds a style check at its top. Neither touches the exponent tail this PR changes, but whichever lands second may need a rebase.

---

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