> If the member used to read the contents of a union object is not the same as the member last used to store a value in the object the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called type punning). This might be a non-value representation.
In past standards, it said "trap representation" rather than "non-value representation," but in none of them did it say that union type punning was undefined behavior. If you have a PDF of any standard or draft standard, just doing a search for "type punning" should direct you to this footnote quickly.
So I'm going to say that if the GCC developer explicitly said that union type punning was undefined behavior in C, then they were wrong, because that's not what the C standard says.
> (11) The values of bytes that correspond to union members other than the one last stored into (6.2.6.1).
So it's a little more constrained in the ramifications, but the outcomes may still be surprising. It's a bit unfortunate that "UB" aliases to both "Undefined behavior" and "Unspecified behavior" given they have subtly different definitions.
From section 4 we have:
> A program that is correct in all other aspects, operating on correct data, containing unspecified behavior shall be a correct program and act in accordance with 5.1.2.4.
> Type punning via unions is undefined behavior in both c and c++.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141#c13
Feel free to start a discussion on the GCC mailing list.
https://news.ycombinator.com/item?id=43794268
Taking snippets of the C standard out of context of the whole seems to result in misunderstandings on this.
Edit: no, it's still in the unspecified behavior annex, that's my mistake. It's still not undefined, though.
That said, I am going to defer to the GCC developers on this since I do not have time to make sense of all versions of the C standard.
That said, using “the code compiles in godbolt” as proof that it is not relying on what the standard specifies to be UB is fallacious.
> Type punning via unions is undefined behavior in both c and c++.
I just was citing the source of this for reference.