[Mono-dev] Patch for IntPtr bug

[Rodrigo Kumpera]

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> 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 ,
> 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]
> *Sent:* 11 February 2009 17:01
> *To:* Russell Kay
> *Cc:* 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>
>
> 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
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090211/0bd04047/attachment-0001.html