[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Pnet-developers] [bug #4535] mscorlib value types being marked as regul
From: |
nobody |
Subject: |
[Pnet-developers] [bug #4535] mscorlib value types being marked as regular classes |
Date: |
Wed, 30 Jul 2003 20:49:30 -0400 |
User-agent: |
Mozilla/5.0 (compatible; Konqueror/3.1; Linux) |
=================== BUG #4535: LATEST MODIFICATIONS ==================
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4535&group_id=353
Changes by: Rhys Weatherley <address@hidden>
Date: Thu 07/31/2003 at 00:49 (GMT)
------------------ Additional Follow-up Comments ----------------------------
The information that indicates that a type is a value type
is stored in the library assembly, not in the referencing
assembly. There is no way in metadata to record this
in the reference.
The ildasm program only dumps a single assembly at a
time, without loading the dependencies. And so sometimes
it needs to guess as to what the foreign type is. This can
cause it to show "class" when you might expect "valuetype",
especially for "box" and "initobj" instructions.
Besides, the IL_META_TYPEDEF_VALUE_TYPE flag
is *not* used to mark value types. A value type is anything
that inherits from "System.ValueType". That flag is obsolete
and is not used any more by the ECMA specifications.
The runtime engine, which does load the dependencies,
will resolve the type, discover that it inherits from the
System.ValueType class, and then "know" that it is a
value type.
Do you have a test case that demonstrates a problem at
runtime, or was it just something you noticed in ildasm?
=================== BUG #4535: FULL BUG SNAPSHOT ===================
Submitted by: Rich333 Project: DotGNU Portable.NET
Submitted on: Wed 07/30/2003 at 18:17
Category: None Severity: 5 - Major
Bug Group: None Resolution: None
Assigned to: None Status: Open
Summary: mscorlib value types being marked as regular classes
Original Submission: The basic mscorlib value types (e.g. Int32, Char) are
being marked as regular classes when referenced from other assemblies. This is
causing things like initobj on these types to fail verification. Within
mscorlib they seem to be treated properly. You can see things like "box
class [mscorlib]System.Char" by "ildasm pnetlib/System/System.dll | grep
System.Char". The problem appears to be in the ILClass attributes for these
types. I printf'd the attribs for System.Char (at least, that's what the
classInfo's ILClassName said it was) in the INITOBJ case in verify_obj.c and it
came out as 0x2109. I'm not sure if the missing IL_META_TYPEDEF_SYSTEM_MASK
bits are a part of the problem, but I know the missing
IL_META_TYPEDEF_CLASS_SEMANTICS_MASK bits are.
Rich
Follow-up Comments
*******************
-------------------------------------------------------
Date: Thu 07/31/2003 at 00:49 By: rweather
The information that indicates that a type is a value type
is stored in the library assembly, not in the referencing
assembly. There is no way in metadata to record this
in the reference.
The ildasm program only dumps a single assembly at a
time, without loading the dependencies. And so sometimes
it needs to guess as to what the foreign type is. This can
cause it to show "class" when you might expect "valuetype",
especially for "box" and "initobj" instructions.
Besides, the IL_META_TYPEDEF_VALUE_TYPE flag
is *not* used to mark value types. A value type is anything
that inherits from "System.ValueType". That flag is obsolete
and is not used any more by the ECMA specifications.
The runtime engine, which does load the dependencies,
will resolve the type, discover that it inherits from the
System.ValueType class, and then "know" that it is a
value type.
Do you have a test case that demonstrates a problem at
runtime, or was it just something you noticed in ildasm?
CC list is empty
No files currently attached
For detailed info, follow this link:
http://savannah.gnu.org/bugs/?func=detailbug&bug_id=4535&group_id=353
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/