[Mono-devel-list] Bad IL generated for IntPtr -> int32 cast?
Miguel de Icaza
miguel at ximian.com
Wed Jul 2 21:23:03 EDT 2003
> In working on more 64 bit issues I have discovered some code inside corlib
> for some IntPtr casts which I think is wrong. This:
> public static explicit operator int (IntPtr value)
> return (int) value.value;
> generates the folowing IL.
> // method line 621
> .method public static hidebysig specialname
> default int32 op_Explicit(native int value) cil managed
> .param 
> // Method begins at RVA 0x8015
> // Code size 8 (0x8)
> .maxstack 8
> IL_0000: ldarga.s 0
> IL_0002: ldfld void* System.IntPtr::value
> IL_0007: ret
> } // end of method IntPtr::default int32 op_Explicit(native int value)
I think Paolo noticed something along these lines, but at the time it
was not a show-stopper, so I had not looked into this.
Knowing that this is a problem for you, I will look into this.
> and there is no conv.i4 generated. You will probably get away with this for
> a little endian machine even if 64bits but for a big endian 64 bit machine
> the conversion actually does something to get the low order 32 bits of the
> value. (as necessary when converting the result of Marshal.OffsetOf into an
> I think pointer -> int conversions should always generate this IL (which no
> doubt JITs can optimize away).
> This code is from the 0.25 corlib.dll as in the tarball - I haven't built it
> myself - and I haven't looked at mcs to see how to fix it (I assume this was
> built using mcs).
Yes, they were built with MCS.
More information about the Mono-devel-list