From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-help-return-55856-listarch-gcc-help=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 22577 invoked by alias); 18 Sep 2014 00:12:36 -0000
Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-help.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-help/>
List-Post: <mailto:gcc-help@gcc.gnu.org>
List-Help: <mailto:gcc-help-help@gcc.gnu.org>
Sender: gcc-help-owner@gcc.gnu.org
Received: (qmail 22564 invoked by uid 89); 18 Sep 2014 00:12:35 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-HELO: mail-la0-f49.google.com
Received: from mail-la0-f49.google.com (HELO mail-la0-f49.google.com) (209.85.215.49) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Thu, 18 Sep 2014 00:12:34 +0000
Received: by mail-la0-f49.google.com with SMTP id pn19so126227lab.36        for <gcc-help@gcc.gnu.org>; Wed, 17 Sep 2014 17:12:31 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.112.149.36 with SMTP id tx4mr514029lbb.79.1410999151274; Wed, 17 Sep 2014 17:12:31 -0700 (PDT)
Received: by 10.112.142.7 with HTTP; Wed, 17 Sep 2014 17:12:31 -0700 (PDT)
In-Reply-To: <60F6FAE47D1BCE4380CC06D18F49789B93F81D6D@NTXBOIMBX02.micron.com>
References: <60F6FAE47D1BCE4380CC06D18F49789B93F81C6E@NTXBOIMBX02.micron.com>	<CAH6eHdT4O3kwTwE-bhQ56uWwyZC_K7wcSnJkKzVcuXM+W3Mneg@mail.gmail.com>	<60F6FAE47D1BCE4380CC06D18F49789B93F81CD4@NTXBOIMBX02.micron.com>	<5419CD78.9040703@redhat.com>	<60F6FAE47D1BCE4380CC06D18F49789B93F81D6D@NTXBOIMBX02.micron.com>
Date: Thu, 18 Sep 2014 00:12:00 -0000
Message-ID: <CAH6eHdTxe0z0kOgnpsx+dUVFe3ugk9HH4oNwcWOJKr2XcQZKTw@mail.gmail.com>
Subject: Re: Possible bug in gcc 4.4.7
From: Jonathan Wakely <jwakely.gcc@gmail.com>
To: "Andy Falanga (afalanga)" <afalanga@micron.com>
Cc: Andrew Haley <aph@redhat.com>, "gcc-help@gcc.gnu.org" <gcc-help@gcc.gnu.org>
Content-Type: text/plain; charset=UTF-8
X-IsSubscribed: yes
X-SW-Source: 2014-09/txt/msg00102.txt.bz2

On 17 September 2014 21:34, Andy Falanga (afalanga) wrote:
> Thank you for the reference.  I'm going to have to think on this for a bit.  I read a bit of the definition for reinterpret_cast in the C++ Draft I have too.  I want to figure this out for sure.

I think you're barking up the wrong tree if you're trying to
understand when reinterpret_cast is suitable ... because it is almost
never a good idea!  reinterpret_cast basically means "just shut up and
do this cast, I know what I'm doing", but that means you've lost the
advantages of having the compiler do type checking.

The rules Andrew quoted say when it's OK to violate the language's
type system. If you try to break those rules you can use
reinterpret_cast to make the compiler shut up and do what it's told,
but you're still breaking the rules.