[Mono-bugs] [Bug 49802][Nor] Changed - do_mono_metadata_parse_type lacks support for CMOD_OPT

bugzilla-daemon@bugzilla.ximian.com bugzilla-daemon@bugzilla.ximian.com
Sat, 18 Oct 2003 11:01:36 -0400 (EDT)


Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

Changed by vargaz@freemail.hu.

http://bugzilla.ximian.com/show_bug.cgi?id=49802

--- shadow/49802	2003-10-17 20:02:33.000000000 -0400
+++ shadow/49802.tmp.11334	2003-10-18 11:01:36.000000000 -0400
@@ -32,6 +32,56 @@
 Any hints?
 
 ------- Additional Comments From karl@waclawek.net  2003-10-17 20:02 -------
 Created an attachment (id=5654)
 Zipped .exe that produces the reported error
 
+
+------- Additional Comments From vargaz@freemail.hu  2003-10-18 11:01 -------
+First of all, PEVerify fails to verify the attached executable:
+
+Microsoft (R) .NET Framework PE Verifier  Version 1.1.4322.573
+Copyright (C) Microsoft Corporation 1998-2002. All rights reserved.
+
+[IL]: Error: [c:\users\zovarga\share\shapechanger.exe :
+Borland.Vcl.ComCtrls.TToolBar::CustomDraw] [offset 0x00000030] [opcode
+callvirt] [found address of value class 'Borland.Vcl.Types.TRect']
+[expected value class 'Borland.Vcl.Types.TRect'] Unexpected type on
+the stack.
+
+So the executable is invalid, and the creator of the executable should
+be fixed.
+
+About the actual problem on mono: the problem is the following
+signature (in ilasm) syntax:
+    object modopt(Borland.Vcl.Variants.Variant) &
+
+According to the spec, this should be encoded as follows:
+   0x20   [TYPE_CMOD_OPT]
+   <encoded TypeRef for Borland.Vcl... class>
+   0x10   [bytef]
+
+Instead of this, it is encoded as:
+   0x10
+   0x20
+
+According to the spec (section 22.2.10), this encoding is not valid.
+
+Interestingly, MS ilasm produces the same encoding, so it is valid
+after all ? Also, if I change the type to
+   object & modopt(Borland.Vcl.Variants.Variant)
+
+the encoding produced by ilasm changes to 0x20 0x10 (the correct one),
+and the two types do not seem to match. So it seems like the CLR
+treats the two types as different.
+
+So either this is a bug in ilasm or a bug in the spec.
+
+Feel free to point the developers of the compiler which produced
+the executable (was it Delphi.Net?) to this bug.
+
+
+
+
+
+
+