Skip to content

Support parsing snan #11573

Open
Open
@tannergooding

Description

The IEEE 754:2008 specification requires that we be able to recover a string matching "snan" (case-insensitive) with an optional preceding sign. We are not required to recover this to an actual snan and are permitted to silently convert it to a qnan (such as double.NaN or float.NaN) instead.

@jkotas raised some concern around this on https://github.com/dotnet/coreclr/issues/19802 given that it may require a new public surface and due to it not being unusual to have NaN checked for by string comparison

At a minimum, we should update the invariant culture to check for snan and return double.NaN or float.NaN. Optionally, and if it is determined to not be breaking, we can add a NumberFormatInfo.SignallingNaN and provide culture specific snan information.

I don't believe either of these should be considered breaking since we are only parsing new values. What could be breaking is if we start formatting snan to NumberFormatInfo.SignallingNaN, as that may break existing code that checks for NaN by string comparison (we currently don't, as IEEE allows us to silently convert a signalling NaN into the quiet nan string: "NaN").

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions