https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77686
--- Comment #18 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 27 Sep 2016, redi at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77686 > > --- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #14) > > Just to explain a little bit. Consider > > > > void foo (void) > > { > > union { float f; char c[4]; } u, v; > > *(int *)&u = 0; > > v = u; > > return *(int *)&v; > > } > > > > then C11 6.5/6,7 make it clear that it is not valid to use 'u' (of union > > type) > > to access the object which now has effective type 'int' (in fact that store > > alone, given strict reading of C11 6.5/6 is invalid as u has a declared > > type). > > The union does not have 'int' amongst its members. Putting 'char' or an > > array of 'char' into the union does not make the access fall under 6.5/7 > > as 'a character type' only follows 'an aggregate or union type that includes > > one > > of the _AFOREMENTIONED_ types...' (emphasis mine). > > But would *(int*)u.c be OK, because that is a character type? Given that C++ > does define what the assignment means for the union, we just need to make sure > we do *(int*)u.c not *(int*)&u or is that still not enough? No, *(int *)u.c is not OK, because that's still 'int', not a character type (because of the cast). > If not, what does the last bullet of 6.5/7 allow? It allows *(char *)&u basically it allows a memcpy implementation to exist.
