Compile

if ((int)MathF.Floor(float.PositiveInfinity) > 0)
    Console.WriteLine("This is .NET 9.0");
else
    Console.WriteLine("This is .NET 8.0");

using either of these project files:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

or

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

On my computer, the program will correctly identify which project file you used, regardless of whether you compile it in debug or release mode.

The Watch window in VS 2022 (17.13.3) reports that (int)MathF.Floor(float.PositiveInfinity) is -2147483648 regardless of which runtime was targeted, but despite that, the > 0 branch is taken on .NET 9.

Dumping the two Release DLLs in ildasm shows no meaningful differences.

Environment.Version is 8.0.14 or 9.0.3.

Edits after the question was answered:
Yes, my computer is x86-64.
The VS Watch window does not (yet?) perform saturating conversions when debugging a .NET 9 application.

Compile

if ((int)MathF.Floor(float.PositiveInfinity) > 0)
    Console.WriteLine("This is .NET 9.0");
else
    Console.WriteLine("This is .NET 8.0");

using either of these project files:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

or

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net9.0</TargetFramework>
    <ImplicitUsings>enable</ImplicitUsings>
  </PropertyGroup>
</Project>

On my computer, the program will correctly identify which project file you used, regardless of whether you compile it in debug or release mode.

The Watch window in VS 2022 (17.13.3) reports that (int)MathF.Floor(float.PositiveInfinity) is -2147483648 regardless of which runtime was targeted, but despite that, the > 0 branch is taken on .NET 9.

Dumping the two Release DLLs in ildasm shows no meaningful differences.

Environment.Version is 8.0.14 or 9.0.3.

Edits after the question was answered:
Yes, my computer is x86-64.
The VS Watch window does not (yet?) perform saturating conversions when debugging a .NET 9 application.

• c#
• asp-core
• -core

• 1 Checking the assembly generated via LINQPad shows very different behavior for 9 vs 8. I've no explanation, very curious as to the answer on this though. – gilliduck Commented Mar 13 at 8:02
• For me, testing in .NET Fiddle .NET 9 in shows the result of (int)MathF.Floor(float.PositiveInfinity) to be 2147483647 not -2147483648 as you have stated above – phuzi Commented Mar 13 at 9:08
• This sounds a bit like an XY problem. Why care about the result of the cast and not the fact that the input is float.PositiveInfinity ? Is there a float operation that wasn't checked for overflow until after the cast? – Panagiotis Kanavos Commented Mar 13 at 9:21

1 Answer 1

This is related to this change, where all the floating-point-to-integer conversions now have saturating behaviour on x86/x64 machines.

Before the change, the result of converting a floating point number to int will always be int.MinValue as long as the value is outside of the range of int. After the change, the result will be int.MaxValue when the value is larger than int.MaxValue, and int.MinValue when the value is smaller than int.MinValue.

The reason for this change is

This change was made to standardize all floating point-to-integer conversions to have saturating behavior and to make the behavior deterministic.

Case in point: I cannot actually reproduce the behaviour in your code on an Apple M4 MacBook.

See also a similar issue reported on the GitHub repo.