https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #24 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Mon, 27 Oct 2014, terra at gnome dot org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645 > > --- Comment #22 from M Welinder <terra at gnome dot org> --- > >Given > > > > GnmExprBinary res; > > GnmExpr const *expr = (GnmExpr *)&res; > > > >the C standard does not define where the result of the conversion points; > > How do you read C99's Section 6.5 #7, then? It only applies if you have validly obtained lvalues of different types referring to overlapping objects. Sometimes pointer conversions will obtain those; sometimes they won't. The C model of pointer conversions is *not* "pointers point to a particular byte address, and conversions just change the type but not the byte address". It's much more restricted that that. Unless there are particular statements in the C standard that say what the resulting pointer points to (e.g. the statements about conversion from a pointer to a structure to a pointer to its first member, and back, *when you have a structure object in the first place*, or about conversions to pointers to character type), the result is not specified. But if you have a union between float and int, take a pointer to the first member, and cast that pointer to type float *, there is no guarantee that the result is a pointer to the float member, absent a specific statement that defines the result of such a conversion (whereas if you cast indirectly, first to a pointer to the union then to float *, you would get a pointer to the float member). And even when you have pointers to the two members of the union, you are still restricted in using them together (see DR#236) - that is the point at which 6.5#7 comes in. But a simple cast from int * to float * doesn't even get that far - the value of the result is unspecified beyond what you get on converting it back to int *.
