[Mono-devel-list] Bad IL generated for IntPtr -> int32 cast?

[Miguel de Icaza]

Hello Bernie,

> 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 [1]
>         // 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
> int.
> 
> 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.

Miguel