------- Additional Comments From falk at debian dot org 2005-02-24 12:59
-------
(In reply to comment #2)
> (In reply to comment #1)
> > Invalid for the same reason as PR 20184...
> >
>
> I get the same failure if I use (little endian system)
> inline data::operator uint64 () const
> { return *reinterpret_cast<const uint64*>(this); }
Okay, once again. The ISO C++ standard says (3.10:15):
If a program attempts to access the stored value of an object through
an lvalue of other than one of the following types the behavior is
undefined:
-- the dynamic type of the object,
-- a cv-qualified version of the dynamic type of the object,
-- a type that is the signed or unsigned type corresponding to the
dynamic type of the object,
-- a type that is the signed or unsigned type corresponding to a
cv-qualified version of the dynamic 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),
-- a type that is a (possibly cv-qualified) base class type of the
dynamic type of the object,
-- a char or unsigned char type.
You are accessing an object of type "class data" through an lvalue of type
"uint64". The type "uint64" here matches none of the mentioned cases; therefore,
the behavior is undefined. This means that printing 0000000000000000, printing
0804836d00000000, crashing, or formatting your hard disk are all correct
results of your code, and there is no bug in the compiler for generating
code that does this.
--
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20185
