Hash function returns different result in F# and C#

[liboz]

The Hash function returns always returns 0 for null values in C#, but in F# calling the hash function with a null value can result in a NullReferenceException.

I discovered it while working on #2096. When the GetHashCode function is small enough in size, it causes the Hash function to return 0 in debug mode and not a NullReferenceException .

Repro steps

1. Create an F# library:

module Test

type Class1 = A |B

let test = Operators.hash (Unchecked.defaultof<Class1>)

2. Create a C# console application with the following code:

using Microsoft.FSharp.Core;

namespace ConsoleApplication
{
    class Program
    {

        static void Main(string[] args)
        {
            Test.Class1 a = null;
            System.Console.WriteLine(Operators.Hash(a));
            System.Console.WriteLine(Test.test);
        }

    }
}

3. Reference the F# library created in step 1 in the C# application created in step 2.

4. Build/Run the solution in Release or Debug configuration with any bitness.

Expected behavior

The same result is printed twice.

Actual behavior

The output is 0 for the first line followed by a NullReferenceException

Known workarounds

None.

Related information

Provide any related information

• Operating system: Windows 10
• Branch: F# 4.0 and master
• .NET Runtime, CoreCLR or Mono Version: .NET 4.6
• Editing Tools (e.g. Visual Studio Version): Visual Studio 2015

[liboz]

This appears to be an issue with FSharp inlining the hash function, which results in the null check in GenericHashParamObj being removed and thus it always tries to call GetHashCode instead of just setting null values to 0.

[dsyme]

I think this is the same as this request - handle null gracefully, even for types that don't have null as a normal value fsharp/fslang-suggestions#92

[liboz]

@dsyme Not quite. The issue is that because of inlining, hash is different in C# vs F#. One way that could be solved is if the null was handled gracefully all the time.

[cartermp]

Note that this only appears to be the case for things like Unchecked.defaultof on an F# type:

type R = { IntVal: int }
hash Unchecked.defaultof<R> // throws

and

type DU = A | B
hash Unchecked.defaultof<DU>

When doing it to a .NET type or an F# class with AllowNullLiteral then

let s: string = null
hash s // gives 0

[<AllowNullLiteral>]
type C() = class end
let c: C = null
hash c // gives 0

[<AllowNullLiteral>]
type C() = class end
hash Unchecked.defaultof<C> // gives 0

This somewhat makes sense, since F#-defined types are a little special in that they do not allow you to initialize them as null outside of Unchecked.defaultof, which then gets you into unsafe-ish territory.

So I think this should still be done, but the impact isn't terribly high.