Skip to content

Fix incorrect case sensitivity in floating-point number parsing methods #11641

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

PopSlime
Copy link

@PopSlime PopSlime commented Aug 4, 2025

Summary

The Single.Parse, Single.TryParse, Double.Parse, and Double.TryParse methods are case-insensitive in .NET Core 3.0 and later, when parsing string representations of PositiveInfinity, NegativeInfinity, and NaN.

References

@PopSlime PopSlime requested a review from a team as a code owner August 4, 2025 13:32
@dotnet-policy-service dotnet-policy-service bot added the community-contribution Indicates that the PR has been added by a community member label Aug 4, 2025
Copy link
Contributor

Tagging subscribers to this area: @dotnet/area-system-runtime

Copy link
Contributor

@gewarren gewarren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a suggestion to try and make it more clear that all of the symbols are compared case insensitively.

@@ -4814,7 +4814,7 @@ The following code example illustrates the use of <xref:System.Double.NegativeIn
## Remarks
In .NET Core 3.0 and later, values that are too large to represent are rounded to <xref:System.Double.PositiveInfinity> or <xref:System.Double.NegativeInfinity> as required by the IEEE 754 specification. In prior versions, including .NET Framework, parsing a value that was too large to represent resulted in failure.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
In .NET Core 3.0 and later, values that are too large to represent are rounded to <xref:System.Double.PositiveInfinity> or <xref:System.Double.NegativeInfinity> as required by the IEEE 754 specification. In prior versions, including .NET Framework, parsing a value that was too large to represent resulted in failure.
In .NET Core 3.0 and later versions, values that are too large to represent are rounded to <xref:System.Double.PositiveInfinity> or <xref:System.Double.NegativeInfinity> as required by the IEEE 754 specification. In prior versions, including .NET Framework, parsing a value that's too large to represent results in failure.

@@ -4814,7 +4814,7 @@ The following code example illustrates the use of <xref:System.Double.NegativeIn
## Remarks
In .NET Core 3.0 and later, values that are too large to represent are rounded to <xref:System.Double.PositiveInfinity> or <xref:System.Double.NegativeInfinity> as required by the IEEE 754 specification. In prior versions, including .NET Framework, parsing a value that was too large to represent resulted in failure.

The `s` parameter can contain the current culture's <xref:System.Globalization.NumberFormatInfo.PositiveInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NegativeInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NaNSymbol%2A?displayProperty=nameWithType>, or a string of the form:
The `s` parameter can contain the current culture's <xref:System.Globalization.NumberFormatInfo.PositiveInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NegativeInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NaNSymbol%2A?displayProperty=nameWithType> (the string comparison is case-insensitive in .NET Core 3.0 and later, but is case-sensitive in prior versions including .NET Framework), or a string of the form:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
The `s` parameter can contain the current culture's <xref:System.Globalization.NumberFormatInfo.PositiveInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NegativeInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NaNSymbol%2A?displayProperty=nameWithType> (the string comparison is case-insensitive in .NET Core 3.0 and later, but is case-sensitive in prior versions including .NET Framework), or a string of the form:
The `s` parameter can contain the current culture's <xref:System.Globalization.NumberFormatInfo.PositiveInfinitySymbol%2A?displayProperty=nameWithType>, <xref:System.Globalization.NumberFormatInfo.NegativeInfinitySymbol%2A?displayProperty=nameWithType>, or <xref:System.Globalization.NumberFormatInfo.NaNSymbol%2A?displayProperty=nameWithType> symbol. This string comparison is case-insensitive in .NET Core 3.0 and later versions, but is case-sensitive in prior versions including .NET Framework. The `s` parameter can also be a string of the form:

@gewarren gewarren requested a review from tannergooding August 4, 2025 17:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-System.Runtime community-contribution Indicates that the PR has been added by a community member
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants