http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49171
--- Comment #6 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2012-10-03 18:46:09 UTC --- (In reply to comment #5) > Ok, thanks. Sorry about the naive question: is it already clear what it means > for reinterpret_cast uses to be "well-defined" in this sense? This is surely no naive question. I should have been more specific: I think only those reinterpret_cast operations that have a *specified* result, should be allowed (similar to relational or equality operations). For example "An expression of integral, enumeration, pointer, or pointer-to-member type can be explicitly converted to its own type; such a cast yields the value of its operand." seems well specified and uncontroversial to me. Another example (and this is relevant for std::addressof) is the combination of p7 "An object pointer can be explicitly converted to an object pointer of a different type. [..] Converting a prvalue of type “pointer to T1” to the type “pointer to T2” (where T1 and T2 are object types and where the alignment requirements of T2 are no stricter than those of T1) and back to its original type yields the original pointer value." and p11 "An lvalue expression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. That is, a reference cast reinterpret_cast<T&>(x) has the same effect as the conversion *reinterpret_cast<T*>(&x) with the built-in & and * operators (and similarly for reinterpret_cast<T&&>(x))." In other words, the whole expression reinterpret_cast<T*>(&const_cast<char&>( reinterpret_cast<const volatile char&>(t))) that is typically used for the real address deduction seems to have well-specified behaviour and should thus be "constexpr-friendly".
