error CS0019: Operator '>' cannot be applied to operands of type 'Image' and 'Image'

[greenozon]

Erroneous output

			foreach (PdfName key in pdfDictionary.Keys)
			{
				PdfObject pdfObject = pdfDictionary.Get(key);
				PdfObject pdfObject2 = pdfReader.GetPdfObject(((PRIndirectReference)pdfObject).Number);
				if (smethod_2(pdfObject2) > Class13.image_0)
				{
					list_1.Add(smethod_2(pdfObject2));
				}
			}


IL:


			// PdfObject pdfObject2 = pdfReader.GetPdfObject(((PRIndirectReference)pdfObject).Number);
			IL_0074: ldloc.0
			IL_0075: ldloc.s 4
			IL_0077: castclass [itextsharp]iTextSharp.text.pdf.PRIndirectReference /* 010000F9 */
			IL_007c: callvirt instance int32 [itextsharp]iTextSharp.text.pdf.PdfIndirectReference::get_Number() /* 0A00020B */
			IL_0081: callvirt instance class [itextsharp]iTextSharp.text.pdf.PdfObject [itextsharp]iTextSharp.text.pdf.PdfReader::GetPdfObject(int32) /* 0A00020C */
			IL_0086: stloc.s 5
			// if (smethod_2(pdfObject2) > Class13.image_0)
			IL_0088: ldloc.s 5
			IL_008a: call class [System.Drawing]System.Drawing.Image ns0.DashboardForm::smethod_2(class [itextsharp]iTextSharp.text.pdf.PdfObject) /* 060000B5 */
			IL_008f: ldsfld class [System.Drawing]System.Drawing.Image ns0.Class13::image_0 /* 0400020F */
			IL_0094: cgt.un
			IL_0096: brfalse.s IL_00aa

error CS0019: Operator '>' cannot be applied to operands of type 'Image' and 'Image'

dnSpy gens OK code:

		foreach (PdfName pdfName in pdfDictionary.Keys)
		{
			PdfObject pdfObject = pdfDictionary.Get(pdfName);
			PdfObject pdfObject2 = pdfReader.GetPdfObject(((PRIndirectReference)pdfObject).Number);
			if (smethod_2(pdfObject2) != Class13.image_0)
			{
				this.list_1.Add(DashboardForm.smethod_2(pdfObject2));
			}
		}

Details

• ILSpy version 9.1.0.7988+03b7444943e720b3134d296c0c8dd3876f8ea4ce
• .NET version 8.0.15+50c4cb9fc31c47f03eac865d7bc518af173b74b7

[ElektroKill]

dnSpy's old ILSpy 2 engine decompiles this correctly. According to the specification, cgt.un can be used to check for inequality of object references.

"cgt.un is allowed and verifiable on ObjectRefs (O). This is commonly used when comparing an ObjectRef with null (there is no “compare-not-equal” instruction, which would otherwise be a more obvious solution)" - ECMA III.1.5 - Operand type table, Table III.4: Binary Comparison or Branch Operations, Note 2

dnSpy, and the old ILSpy v2 engine, has a direct check for this scenario:

ILSpy/ICSharpCode.Decompiler/Ast/AstMethodBodyBuilder.cs

Lines 450 to 463 in 6a58560

	case ILCode.Cgt_Un: {
	// can also mean Inequality, when used with object references
	TypeReference arg1Type = byteCode.Arguments[0].InferredType;
	if (arg1Type != null && !arg1Type.IsValueType) goto case ILCode.Cne;
	// when comparing signed integral values using Cgt_Un with 0
	// the Ast should actually contain InEquality since "(uint)a > 0u" is identical to "a != 0"
	if (arg1Type.IsSignedIntegralType())
	{
	var p = arg2 as Ast.PrimitiveExpression;
	if (p != null && p.Value.IsZero()) goto case ILCode.Cne;
	}
	goto case ILCode.Cgt;

The new decompiler only seems to handle this case when the one of the sides is ldnull:

ILSpy/ICSharpCode.Decompiler/IL/Transforms/EarlyExpressionTransforms.cs

Lines 55 to 80 in 7218a63

	if (inst.Right.MatchLdNull())
	{
	if (inst.Kind == ComparisonKind.GreaterThan)
	{
	context.Step("comp(left > ldnull) => comp(left != ldnull)", inst);
	inst.Kind = ComparisonKind.Inequality;
	}
	else if (inst.Kind == ComparisonKind.LessThanOrEqual)
	{
	context.Step("comp(left <= ldnull) => comp(left == ldnull)", inst);
	inst.Kind = ComparisonKind.Equality;
	}
	}
	else if (inst.Left.MatchLdNull())
	{
	if (inst.Kind == ComparisonKind.LessThan)
	{
	context.Step("comp(ldnull < right) => comp(ldnull != right)", inst);
	inst.Kind = ComparisonKind.Inequality;
	}
	else if (inst.Kind == ComparisonKind.GreaterThanOrEqual)
	{
	context.Step("comp(ldnull >= right) => comp(ldnull == right)", inst);
	inst.Kind = ComparisonKind.Equality;
	}
	}

Perhaps changing the check here from inst.Right.MatchLdnull() to inst.Right.ResultType == StackType.O, and similarly for left hand side, would solve this issue. Hard to verify without access to a file with such IL.

[siegfriedpammer]

Adding the Obfuscated label because the code snippets posted in the OP strongly resemble obfuscated/partially deobfuscated code.