[fabrianivan]

Problem

1. Bare dot treated as zero: In trimDecimal, strings containing only a dot or signed dot (".", "+.", "-.") match stringNumberRe (^([-+]?\d*)(\.\d*)?$). Because digits before and after the dot are both optional, the empty integer part is captured and mapped to "0", "+0", or "-0". As a result, cast.ToIntE(".") returns 0, nil without error, while cast.ToFloat64E(".") and strconv.ParseFloat fail with syntax errors.
2. Multiple plus signs accepted: In parseUint, strings.TrimLeft(..., "+") was used, which strips all leading plus signs. Consequently, invalid numeric strings like "++5" or "+++5" were parsed as 5, nil instead of being rejected.

Solution

1. In trimDecimal, immediately return s when s is ".", "+.", or "-." so strconv.ParseInt and strconv.ParseUint can reject it with strconv.ErrSyntax.
2. In parseUint, use strings.TrimPrefix(..., "+") instead of strings.TrimLeft so only a single optional leading plus sign is stripped.

Verification

• Added test cases in number_internal_test.go and number_test.go (TestInvalidNumberStrings) for ".", "+.", "-.", and "++5".
• Verified all tests pass cleanly with go test -v -race ./... and go vet ./....

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}