Possible bug in gcc 4.4.7

[Jonathan Wakely]

On 18 September 2014 15:24, Andy Falanga (afalanga) <afalanga@micron.com> wrote:
>> -----Original Message-----
>> From: Jonathan Wakely [mailto:jwakely.gcc@gmail.com]
>> Sent: Wednesday, September 17, 2014 6:13 PM
>> To: Andy Falanga (afalanga)
>> Cc: Andrew Haley; gcc-help@gcc.gnu.org
>> Subject: Re: Possible bug in gcc 4.4.7
>>
>> 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.
>
> Thank you for the warning.  In this case, I'm not trying to understand when to violate the rules but, rather, to understand why what I did resulted in undefined behavior.

So looking into reinterpret_cast is not very relevant.

You are using a reference of type unsigned int& to access something
that is not an unsigned int, that's the problem.

The fact you used reinterpret_cast to create the reference is not
relevant, it's what you did with the reference after you created it
that is the problem. This is undefined in the same way, but doesn't
use reinterpret_cast:

Flag f1;
void* vp = &f1;
*static_cast<unsigned int*>(vp) = 1;