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 [EMAIL PROTECTED] http://bugzilla.ximian.com/show_bug.cgi?id=79054 --- shadow/79054 2006-08-11 07:06:11.000000000 -0400 +++ shadow/79054.tmp.1269 2006-08-11 07:51:02.000000000 -0400 @@ -112,6 +112,39 @@ You could also use (void*) as the intermediate cast. I would like to know why this works with CSC.EXE, as msdn2 doesn't list any IntPtr members that work with the UInt64, so either CSC.EXE has an internally-permitted conversion from ulong, or their class library has some members which aren't documented. + +------- Additional Comments From [EMAIL PROTECTED] 2006-08-11 07:51 ------- +When using: + int a = 42; + IntPtr b = (IntPtr)a; + Console.WriteLine(b); + +Microsoft generates a "conv.u8" and use the "op_Explicit(int64)", +rather than using op_Explicit(int32) directly. + +So I think their compiler is indeed allowing the up sizing. + +The IL code snippet is: + + IL_0000: nop + IL_0001: ldc.i4.s 42 + IL_0003: stloc.0 + IL_0004: ldloc.0 + IL_0005: conv.u8 + IL_0006: call native int [mscorlib] +System.IntPtr::op_Explicit(int64) + IL_000b: stloc.1 + IL_000c: ldloc.1 + IL_000d: box [mscorlib]System.IntPtr + IL_0012: call void [mscorlib]System.Console::WriteLine +(object) + IL_0017: nop + IL_0018: ldc.i4.0 + IL_0019: stloc.2 + IL_001a: br.s IL_001c + + IL_001c: ldloc.2 + IL_001d: ret _______________________________________________ mono-bugs maillist - [email protected] http://lists.ximian.com/mailman/listinfo/mono-bugs
