http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50284
--- Comment #4 from Rafael Avila de Espindola <rafael.espindola at gmail dot
com> 2011-09-03 22:54:10 UTC ---
(In reply to comment #3)
> struct Value {
> struct jsval data;
> };
> ...
> struct jsval y = t3.array[i];
> struct Value *z = (struct Value*)&y;
> if (z->data.tag == 0xFFFFFF85) {
>
> that's invalid in GCCs reading of 6.5 p7. jsval is a subset of Value's
> alias-set
> but not the other way around. GCC reads z->data.tag as an access to an
> object of type Value which is invalid.
So downcast (i.e. casting to a more specialized type) are invalid even if
original data type is correct (not that it is in the reduced testcase)? That is
really strict :-(
> The contorted reasoning is that the pointer conversion invokes undefined
> behavior. Definitely an interesting blog post ;)
is there any hope that gcc could be made a bit less strict? Either reading the
member access as not involving an access to the full object or accepting
downcasts (when the original type matches) would work. My preference would be
for the second option, as downcasts are fairly common in OO.
