When does reinterpret_cast modify bits?
c++, casting, reinterpret-cast
Solution
I've worked on platforms where `char*` was larger than `int*`, and on platforms where they had a different layout, even though the size was the same. Neither of the machines in question are particularly relevant today, however (although the second, the PDP-10, was one of the more important machines in its heyday). It's also conceivable that some compilation modes on an Intel in native mode (or what used to be called native mode) would "normalize" pointers in a `reinterpret_cast`, or even an implicit conversion, in order to facilitate address comparisons. It's also conceivable (although I've not seen it) that such conversions enforce correct alignment, e.g. a conversion from `char*` to `int*` might force the 2 low-order bits to 0. In practice, however, I don't think, today, that you're likely to see a `reinterpret_cast` make any changes between data pointer types. The issue is more historic. (But I'm not sure about modern embedded processors. From what I understand, many of them are word addressing, and so if `sizeof(int) != sizeof(char)`, they're likely to need a special format to address `char`.)
Problem
From the C++ standard: 5.2.10.3 The mapping performed by reinterpret_cast might, or might not, produce a representation different from the original value. I've been trained at this very site to believe and repeat this. (Even if it's possibly just trivia). A `reinterpret_cast` from `float*` to `int*` is allowed to produce a different bit pattern. The only guarantee is that `reinterpret_cast`-ing that result back to `float*` will produce the original bit pattern. My question: Does this ever happen? Is there an existing, real-world platform or CPU or compiler that actually `reinterpret_cast`s to a different bit pattern? If not, are there any real-world situations where `reinterpret_cast` has any runtime overhead? In all my experience with `reinterpret_cast`, the cast was a directive to the compiler, not the runtime.