> 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.
