Fix S1940 FP: for floating point numbers that can be NaN "!(a <= b)" is not the same as "a > b"

[tobiass-sdl]

Description

Not sure if this is a FP in the strong sense but the "why is this an issue" text should at least clearly state that the suggested "fix" behaves differently than the original code if a or b is NaN.

public static bool Foo(ReadOnlySpan<double> a, ReadOnlySpan<double> b)
{
   for (; i < a.Length; ++i)
   {
      if (!(a[i] <= b[i])) return false;
   }

   return true;
}

we have several places in our code base that intentionally invert the result of a floating point comparison. Applying the suggestion to remove the invert would cause bugs.

Obviously the solution on our side is to double check that we have unittests that protect against blind application of the so called fix.

Reproducer

public static bool Foo(ReadOnlySpan<double> a, ReadOnlySpan<double> b)
{
   for (; i < a.Length; ++i)
   {
      if (!(a[i] <= b[i])) return false;
   }

   return true;
}

Product and Version

Sonarqube server, Data Center Edition v2025.1 (102418)

[jilles-sg]

Agreed, this kind of thing may cause bugs when people "fix" issues too quickly.

I reported a similar issue for JavaScript a while ago in https://community.sonarsource.com/t/s1940-no-inverted-boolean-check-suggests-breaking-changes-for-floating-point/128556 but in C# it is a little easier because types like integers, decimal, DateOnly, DateTime, DateTimeOffset and TimeOnly have comparison operators that behave normally. On the other hand, not only float and double but also Half and the proposed Decimal32, Decimal64 and Decimal128 have NaN. It is also somewhat likely that custom operator implementations have bugs with values like default.

I think restricting the rule to types with "well-behaved" comparison operators would yield a still useful rule that can safely be applied.