[Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast

["daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>]

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