-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
Roslyn and .Net disagree about converting double.NaN to long #72526
Comments
@tannergooding might have insight about what should happen here. |
As per the IEEE 754 specification, conversion of floating-point values to integers where the input is either not a finite value ( What this ultimately means is that every platform has historically done a different behavior and in order for C# to allow constant folding and determinism, it picked a format that worked for it when these edge cases are encountered. The .NET runtime is moving towards normalizing its behavior across platforms as well: dotnet/runtime#61885 The behavior we standardized on is the behavior that fits in with other platforms (such as Arm64), that is required by certain platforms (such as WASM), and which fits into the general intent of the IEEE 754 floating-point specification with regards to operations. The general intent (and requirement for most operations) is that results are taken as given, computed as if to infinite precision and unbounded range, and then rounded to the nearest representable result. Thus, the behavior the runtime is normalizing on is that float to integer conversions "saturate". Thus, Roslyn currently matches the intended behavior for |
@tannergooding Thanks for the explanation. |
Thanks @tannergooding! I will close out as it looks like the question has been answered. |
Version Used: .Net 8
Steps to Reproduce:
Compile and run the following code:
Expected Behavior:
Both versions produce the same output.
Actual Behavior:
The output is:
I.e. when .Net converts
double.NaN
tolong
at run-time, the result islong.MinValue
. But when Roslyn performs an unchecked conversion of a constantdouble.NaN
tolong
at compile-time, the result is0
.I don't know if this is an issue in Roslyn, in the .Net runtime, or if the inconsistency is expected, but I thought it would be worth reporting nevertheless.
The text was updated successfully, but these errors were encountered: