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

["daniel.kruegler at googlemail dot com" <gcc-bugzilla at gcc dot gnu dot 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".