[matt-edmondson]

Fixes #181

What was wrong

TrimAllowedWhite trimmed with ReadOnlySpan<char>.TrimStart() and TrimEnd(), which remove anything char.IsWhiteSpace accepts: NBSP, U+202F, U+3000, NEL, LS, PS and the other Unicode space separators. NumberStyles allows only U+0009–U+000D and U+0020 as white space, and decimal, double and int reject the rest. Parse/TryParse therefore accepted input that every BCL numeric type refuses. The realistic case is a stray trailing fr-FR group separator, "1 ", under NumberStyles.Integer.

What changed

• The trim now uses an explicit set, " \t\n\v\f\r", held in a documented AllowedWhite constant.

Tests

• Parse_RejectsNonAsciiWhiteSpaceAroundTheNumber covers leading NBSP, trailing U+3000, leading NEL and trailing LS. Each case first asserts that decimal.TryParse rejects the input, then asserts that PreciseNumber.TryParse returns false and Parse throws FormatException.
• Parse_RejectsATrailingNarrowSpaceGroupSeparatorWhenTheStyleDoesNotAllowThousands is the fr-FR case from the issue. It uses the test file's existing NarrowSpaceGroups format rather than fr-FR, so it also runs where the globalization-invariant mode has no culture data.
• Parse_TrimsAsciiWhiteSpaceAroundTheNumber shows that space, tab, CR, LF, VT and FF are still trimmed on both sides.
• With the fix reverted, five cases fail. With the fix, all 559 tests pass, and the Release build is clean.

---

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