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

[Jonathan Pryor]

On Wed, 2004-08-04 at 11:49, Bernie Solomon wrote:
> I agree arguing from what is not stated is a little dangerous. But then if
> it
> isn't stated maybe you end up making assumptions that weren't intended.

Which is why specifications should be very clear. :-)

> I'm also just treating this as a thought exercise out of curiosity...

It's all a thought exercise, until it gets implemented.

> I believe there is more evidence that 128bit pointers (as in ones with
> that amount of information as opposed to some strange storage format
> which uses more space than information) won't work. If you look at
> the spec for integer conversion it states than a native int to int64
> conversion
> is sign extend or zero extend (CONV_I or CONV_U) - to me this
> implies I can write IL that relies on this and is value preserving and
> hence pointers can't have more than 64 bits of information in them.

This doesn't make any sense to me.  How do I sign-extend or zero-extend
a 64-bit IntPtr to a int64?  They're the same size!  No extension is
required at all.

This would really only be a concern when converting a 32-bit IntPtr to
an int64 -- *that's* when you'd have an extension of some form.

Relying on a sign-/zero-extension would likely be non-portable, as
reliance would break 64-bit addressing (the extension would occur with
32-bit pointers, but not 64-bit pointers, resulting in different
performance, resulting in portability issues).

I would hope that the spec would be clarified.

 - Jon