dotgnu-pnet
[Top][All Lists]
Advanced

[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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]