[Mono-dev] Patch for IntPtr bug

[Kornél Pál]

Russell,

The CLI has first class support for IntPtr but C# unfortunately needs to 
call IntPtr methods instead of using opcodes directly. But I believe 
that these methods should be inlined by the runtime. (If not this should 
be tracked in bugzilla.)

And as Rodrigo said you should use unsafe code with pointer if you want 
maximal performance because C# has support for pointers and is using 
"unsigned native int" arythmetic for them.

Also note that pointers are in fact unsigned so you should convert them 
to usingned integers to avoid sign related issues.

And your patch Russell is incorrect because IntPtr is a signed integer 
that is 32-bit on 32-bit architectures this it cannot hold 
UInt32.MaxValue. If you want to hold UInt32.MaxValue you should use UIntPtr.

Kornél

Rodrigo Kumpera wrote:
> IntPtr code should optimize as well as int on 32bits machines and long 
> on 64 bits machine. If it's not the case, report it.
> Working with ints using long will be a lot slower on 32bits machines for 
> sure.
> 
> Regarding doing pointer math, the usual way to do it with C# is to use a 
> block of unsafe code and use proper pointer types.
> 
> 
> On Wed, Feb 11, 2009 at 3:12 PM, <russell.kay at realtimeworlds.com 
> <mailto:russell.kay at realtimeworlds.com>> wrote:
> 
>     Rodrigo,
> 
>      
> 
>     IntPtr objects are very awkward to use and optimise badly, we unwrap
>     an IntPtr to an internal type called Ptr, that is an enum based on a
>     long, as this generates much better code within loops and generally
>     inlines better (on both Mono and MS.Net) we also keep this as a long
>     so that we have the same assembly on both x86 and x64 (which limits
>     our testing).
> 
>      
> 
>     IntPtr is also fairly horrible to work with when you are doing any
>     maths when working with memory operations (which we are doing a lot).
> 
>      
> 
>     Now this is not a problem and works very well on both Mono and
>     MS.NET <http://MS.NET> , when this patch is applied.
> 
>      
> 
>     I do not see the objection to this patch as an IntPtr  can safely
>     hold values that are over 2Gb and they are valid addresses, also
>     converting from a pointer to a long does not sign extend it, which
>     is perfectly valid and at times you do want to convert back to an
>     IntPtr.
> 
>      
> 
>     This is a perfectly safe and sensible patch.
> 
>      
> 
>     Russell
> 
>      
> 
>     *From:* Rodrigo Kumpera [mailto:kumpera at gmail.com
>     <mailto:kumpera at gmail.com>]
>     *Sent:* 11 February 2009 17:01
>     *To:* Russell Kay
>     *Cc:* mono-devel-list at lists.ximian.com
>     <mailto:mono-devel-list at lists.ximian.com>
> 
>     *Subject:* Re: [Mono-dev] Patch for IntPtr bug
> 
>      
> 
>     Russel,
> 
> 
> 
>     I think the issue is that you're using long to represent pointers
>     when you should be using IntPtr only.
> 
>     2009/2/11 <russell.kay at realtimeworlds.com
>     <mailto:russell.kay at realtimeworlds.com>>
> 
>     All,
> 
>      
> 
>     Not sure the best way to submit this, please correct me if there is
>     a better way to do this (via bugzilla?)
> 
>      
> 
>     I encountered a problem when casting a long to an IntPtr, which is
>     something we have ended up doing a lot (we want to keep binary
>     assembly compatibility between x86 and x64, only changing the native
>     code on the different architectures). We encountered a problem with
>     Mono as there has been a check introduced into the IntPtr
>     constructor from a long, this is checking the range of the long to
>     ensure it is in range, unfortunately the check is incorrect. A long
>     can easily hold from Int32.MinValue to UInt32.MaxValue (and not
>     Int32.MaxValue as it currently in there).
> 
>      
> 
>     See attached patch (contributed under the MIT X11 license) to
>     introduce the one extra character that makes the range check correct.
> 
>      
> 
>     Can I also say that I think the check should really be in a
>     Debug.Assert so that it disappears in non-Debug versions, the check
>     is good for sanity checking but superfluous on released code.
> 
>      
> 
>     Regards
> 
>      
> 
>     Russell
> 
> 
>     ____________________________________________________________________
>     DISCLAIMER
> 
>     This message and any attachments contain privileged and confidential
>     information intended for the use of the addressee named above. If
>     you are not the intended recipient of this message, you are hereby
>     notified that any use, dissemination, distribution or reproduction
>     of this message is prohibited. Please note that we cannot guarantee
>     that this message or any attachment is virus free or that it has not
>     been intercepted and amended. The views of the author may not
>     necessarily reflect those of Realtime Worlds Ltd.
> 
> 
> 
>     Realtime Worlds Ltd is registered in Scotland, number 225628.
>     Registered Office: 152 West Marketgait, Dundee, DD1 1NJ.
> 
> 
>     _______________________________________________
>     Mono-devel-list mailing list
>     Mono-devel-list at lists.ximian.com
>     <mailto:Mono-devel-list at lists.ximian.com>
>     http://lists.ximian.com/mailman/listinfo/mono-devel-list
> 
> 
> 
>     ____________________________________________________________________
>     This email has been scanned by the MessageLabs Email Security System
> 
>     ____________________________________________________________________
> 
>     DISCLAIMER
> 
>     This message and any attachments contain privileged and confidential
>     information intended for the use of the addressee named above. If
>     you are not the intended recipient of this message, you are hereby
>     notified that any use, dissemination, distribution or reproduction
>     of this message is prohibited. Please note that we cannot guarantee
>     that this message or any attachment is virus free or that it has not
>     been intercepted and amended. The views of the author may not
>     necessarily reflect those of Realtime Worlds Ltd.
> 
> 
> 
>     Realtime Worlds Ltd is registered in Scotland, number 225628.
>     Registered Office: 152 West Marketgait, Dundee, DD1 1NJ.
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list