Reference type non-null-checks produce incorrect code

switchblade

I've noticed this bug for a while now, I'm not sure when it was introduced but take this simple example here:

private static void ABC(byte[] b)
{
    if (b != null)
    {
        Environment.Exit(0);
    }
}

private static void ABC(List<string> b)
{
    if (b != null)
    {
        Environment.Exit(0);
    }
}

This is the decompiled output:

private static void ABC(byte[] b)
{
    if (b > null)
    {
        Environment.Exit(0);
    }
}

private static void ABC(List<string> b)
{
    if (b > null)
    {
        Environment.Exit(0);
    }
}

It seems to replace the expected "!=" with ">" which is not valid C# code. The same occurs on VB decompilation as well.

PS - The forum seems to be encoding "<" and ">" incorrectly using the code tags, would be nice if you could fix that too.

Jessica R

Sorry to hear you're running into an issue!

It's odd though, I'm not able to reproduce this at the moment.



May I ask the project type and the .NET Framework version of the assembly you're decompiling?

Thanks!

switchblade

The project type is a console application and is compiled with .NET Core 1.0. However I can also repro this issue with a .NET Framework 4 WinForms app. Changing the C# version at the top of Reflector also seems to have no effect. For reference here is the IL which may explain the problem:

.method private hidebysig static void ABC(uint8[] b) cil managed
{
    .maxstack 2
    .locals init (
        [0] bool flag)
    L_0000: nop 
    L_0001: ldarg.0 
    L_0002: ldnull 
    L_0003: cgt.un // -- here?
    L_0005: stloc.0 
    L_0006: ldloc.0 
    L_0007: brfalse.s L_0012
    L_0009: nop 
    L_000a: ldc.i4.0 
    L_000b: call void [mscorlib]System.Environment::Exit(int32)
    L_0010: nop 
    L_0011: nop 
    L_0012: ret 
}

https://stackoverflow.com/questions/28781839/why-does-the-c-sharp-compiler-translate-this-comparison-as-if-it-were-a-com

Jessica R

Hi @switchblade, thanks very much for those details and for the helpful stackoverflow post!

I have been able to reproduce this and as .NET Reflector should still be able to decompile != correctly, I have gone ahead and logged a bug for this internally with reference RP-4045. Thank you and I will let you know once I have any updates.

Just a note that we are also working on the bug where our forum is encoding code incorrectly--thanks for reporting this as well!