[Mono-bugs] [Bug 80307][Wis] Changed - NullReferenceException in ternary operator

[bugzilla-daemon at bugzilla.ximian.com]

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 massi at ximian.com.

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

--- shadow/80307	2007-01-15 14:45:39.000000000 -0500
+++ shadow/80307.tmp.24146	2007-01-16 03:21:54.000000000 -0500
@@ -1,12 +1,12 @@
 Bug#: 80307
 Product: Mono: Runtime
 Version: 1.2
 OS: other
 OS Details: 
-Status: NEW   
+Status: ASSIGNED   
 Resolution: 
 Severity: Unknown
 Priority: Wishlist
 Component: JIT
 AssignedTo: massi at ximian.com                            
 ReportedBy: grendello at gmail.com               
@@ -176,6 +176,21 @@
 returns the original klass for a byref type, not a 'byref' class,
 causing the JIT to create variables with the wrong type".
 I also had big problems with this piece of code when trying to
 implement type based alias analysis for HSSA.
 
 Anyway, I'll investigate more.
+
+------- Additional Comments From massi at ximian.com  2007-01-16 03:21 -------
+As usual, in retrospect it was easy: mono_type_get_underlying_type
+"strips" the byref information from the type.
+I mean, a "System.Web.Compilation.TagType&" (note the final '&')
+becomes a "System.Int32".
+This makes so that, on 64 bit systems, mono_allocate_stack_slots_full
+puts it in a 4 bytes available slot instead of an 8 bytes one: when
+the variable is written it then overwrites (part of) the next slot.
+
+This is easy to fix, but the question is: is this IMHO broken behavior
+of mono_type_get_underlying_type intentional?
+I mean, is there code relying on this?
+If yes, I'll just fix mono_allocate_stack_slots_full, but I would
+prefer fixing mono_type_get_underlying_type instead.