From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25389 invoked by alias); 3 Oct 2012 18:46:24 -0000 Received: (qmail 25364 invoked by uid 48); 3 Oct 2012 18:46:10 -0000 From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/49171] [C++0x][constexpr] Constant expressions support reinterpret_cast Date: Wed, 03 Oct 2012 18:46:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-10/txt/msg00230.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D49171 --- Comment #6 from Daniel Kr=C3=BCgler 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 m= eans > 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, shou= ld 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 =E2=80=9Cpointer to T1=E2= =80=9D to the type =E2=80=9Cpointer to T2=E2=80=9D (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 origin= al type yields the original pointer value." and p11 "An lvalue expression of type T1 can be cast to the type =E2=80=9Creference= to T2=E2=80=9D if an expression of type =E2=80=9Cpointer to T1=E2=80=9D can be explicitly con= verted to the type =E2=80=9Cpointer to T2=E2=80=9D using a reinterpret_cast. That is, a refere= nce cast reinterpret_cast(x) has the same effect as the conversion *reinterpret_cast(&x) with the built-in & and * operators (and similarly for reinterpret_cast(x))." In other words, the whole expression reinterpret_cast(&const_cast( reinterpret_cast(t))) that is typically used for the real address deduction seems to have well-specified behaviour and should thus be "constexpr-friendly".