Comment by ryao
2 days ago
The GCC developers disagree with your interpretation:
> Type punning via unions is undefined behavior in both c and c++.
2 days ago
The GCC developers disagree with your interpretation:
> Type punning via unions is undefined behavior in both c and c++.
I'm not sure tbh what's there to 'interpret' or how a compiler developer could misread that, the wording is quite clear.
It is an excerpt being taken out of context. Of course it is quite clear. Taking it out of context ignores everything else that the standard says. That interpretation is wrong as far as compiler authors are concerned.
The context is that it's a footnote. The footnote is referenced in this paragraph:
A postfix expression followed by the . operator and an identifier designates a member of a structure or union object. The value is that of the named member (106), and is an lvalue if the first expression is an lvalue. If the first expression has qualified type, the result has the so-qualified version of the type of the designated member.
106) 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 that same document, union type punning is explicitly listed under Annex J.1, Unspecified Behavior:
(11) The values of bytes that correspond to union members other than the one last stored into (6.2.6.1).
The standard is extremely clear and explicit that it's not undefined behavior.
4 replies →
I wouldn't be surprised if Andrew Pinski was just wrong. It's anecdotal but my impression of him isn't very good.