[Mono-devel-list] Prevalence of pointer-integral-pointer casting in mono?

[Jonathan Pryor]

On Mon, 2004-08-02 at 22:23, Peter Colson wrote:
<snip/>
> Where does that leave us with respect to the IntPtr and UIntPtr types in
> C# and the requirement for these types to be able to hold a pointer and
> allow those contents to be treated as a pointer?
>
> If the platform concerned has 128-bit pointers and no native integral
> type to hold a pointer, is the ability to support (U)IntPtrs prevented?

IntPtr and UIntPtr are supposed to be large enough to hold a pointer
value.  That's their entire purpose.  So if you're targeting a 128-bit
platform, then IntPtr and UIntPtr should be resized appropriately.

I'm not sure easy this would be to do from the runtime perspective, but
such a change should be transparent to managed code.

> Furthermore, am I right in saying that any .Net-style runtime operating
> on a platform is going to have recourse to using unsafe calls (at least
> internally) requiring the use of (U)IntPtr's, even if C# code written on
> that platform makes no use of unsafe code?

Could you clarify that?

Let's put it this way: as currently implemented, Mono requires the use
of IntPtrs.  Just look at the System.IO source code (IIRC) -- IntPtrs
are used as part of the internal call declarations into the Mono
runtime.  This is pretty much true for any part of the runtime that uses
internal calls (which is a substantial fraction).  If an IntPtr can't
actually hold a pointer, you're screwed.  Period.

Furthermore, the typical times pointer->integer conversions break down
isn't when the integer isn't large enough to hold a pointer -- you can
just use a larger integer and you're fine.  The *real* problems show up
when you have a segmented memory architecture, and there is no integer
large enough to hold a pointer.  In such a case, you may not have an
integer large enough to hold a full pointer (example: the 80286 had a 20
bit address space but only 16-bit integers).

.NET isn't targeted at such platforms.  I doubt Java could handle them
either.  Most C code isn't targeted at such platforms, either.  C
assumes a flat memory address, and hacking C into the 80x86 required
introducing several pointer modifiers (near, far, huge, etc.).  It is
not fun (unless you're a masochist), and most people avoid such
platforms (given a choice).

As a fallback, you could use a structure to hold the full pointer value
and add some pack/unpack logic whenever IntPtr is used.  This would
suck, performance-wise, but it could work.

Furthermore, here's a better follow-up question: what do you do if you
want to run .NET code on platforms that don't have 8-bit bytes? ;-) 
Byte, Int16, Int32, etc., are no longer appropriately sized, and this
could cause compatibility problems.  This limits portability.

(Granted, this isn't a *major* problem today, but it was ~20 years ago.)

 - Jon