> -----Original Message----- > From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On > Behalf Of Andrew Haley > Sent: Wednesday, September 17, 2014 12:06 PM > To: Andy Falanga (afalanga); Jonathan Wakely > Cc: gcc-help@xxxxxxxxxxx > Subject: Re: Possible bug in gcc 4.4.7 > > On 09/17/2014 06:15 PM, Andy Falanga (afalanga) wrote: > > > Ha, nothing except my thinking that, because I was casting a > > reference, I had to use reinterpret_cast<>. Of course, that (your > > suggestion) worked for me. Please point me to the correct section of > > the language spec so that I might better understand why this is > > undefined behavior. > > Here's the C version: > > "6.5 Expressions": > > An object shall have its stored value accessed only by an lvalue > expression that has one of the following types: > > a type compatible with the effective type of the object, > > a qualified version of a type compatible with the effective type > of the object, > > a type that is the signed or unsigned type corresponding to the > effective type of the object, > > a type that is the signed or unsigned type corresponding to a > qualified version of the effective type of the object, > > an aggregate or union type that includes one of the aforementioned > types among its members (including, recursively, a member of a > subaggregate or contained union), or > > a character type. > > C++ uses the same rule. If you access an object using an lvalue > expression of an incompatible type, all bets are off. > > static_cast<Flag>(reinterpret_cast<unsigned int&>(f1) is an example of > such an expression. > > Andrew. 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. Andy
