[Mono-devel-list] Prevalence of pointer-integral-pointercastingin mono?
jonpryor at vt.edu
Wed Aug 4 18:53:37 EDT 2004
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
> 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
> 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.
More information about the Mono-devel-list