Re: does gcc support multiple sizes, or not?

[DJ Delorie <dj at redhat dot com>]

> The "except that" sentence implies the statement above, assuming
> that the pointed-to type does not have stricter alignment.  So, if
> casting a 32-bit pointer to int to a 16-bit pointer to char and back
> does not always yield the same value, then something has to give.

reinterpret_cast doesn't require that the intermediate form have the
same bit pattern.  On the m16c, for example, it's technically possible
to convert from a 24 bit function pointer to a 16 bit pointer to that
function's thunk, and back.  Not *all* pointers can be converted, but
pointers to functions can.  Not that I'd want to write that kind of
support code, but it's possible.

The way I read it, "a pointer" to an object can be converted to "a
pointer" to a different type of object, but as reinterpret_cast
already leaves the const qualifier alone, it seems to be focusing on
the object's type, not the pointer's type.  IMHO, this allows the
interpretation that a "pointer of a given size" to an object can be
cast to a "pointer of the same size" to a different object.

Thus, a "far *foo" can be cast to a "far *bar" and back.


But, this has gone way past what I really needed.  I didn't need to
know if we *should* support multiple pointer sizes, I need to know
*if* we support them, so I know which way to fix the code.  If they're
not supported, I'll work on failing gracefully.  If they are
supported, I'll fix that bug so it works.

If you say C++ doesn't support them, I'll take it out and make it
obvious that C++ doesn't support them, as long as C still supports
them (because I use that feature a lot).  I just don't want it to
crash when the user does something that appears to be legal based on
the gcc manual.