4 ms·

The GCC developers disagree with your interpretation: > Type punning via unions is undefined behavior in both c and c++. https://gcc.gnu.org/bugzilla/show_bug

by ryao 2y ago

The GCC developers disagree with your interpretation: > Type punning via unions is undefined behavior in both c and c++. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141#c13 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118141#c13

flohofwoe 2y ago
I'm not sure tbh what's there to 'interpret' or how a compiler developer could misread that, the wording is quite clear.
- ryao 2y ago
  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.
  - trealira 2y ago
    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.
    - ryao 2y ago
      This is not considering the document as a whole. I will defer to the GCC developers on what the document means on this.
      - trealira 2y ago
        I'm interested in hearing how considering the document as a whole leads to a different conclusion.
      - jcranmer 2y ago
        I am a member of the C standards committee, and I'm telling you you're wrong here. Martin Uecker is also member of the C standards committee, and has just responded to that bug saying that the comment you linked is wrong. I, and others here, have quoted literal standards text to you explaining why type punning through unions is well-defined behavior in C. I don't know who Andrew Pinski is, but they're factually incorrect regarding the legality of type punning via unions in C.
        uecker 2y ago
        Andrew is a GCC developer who is very competent (much more than myself regarding GCC), but I think he was mistakenly assuming the C++ rules apply to C here as well.
nialv7 1y ago
I wouldn't be surprised if Andrew Pinski was just wrong. It's anecdotal but my impression of him isn't very good.

by ryao 2y ago

flohofwoe 2y ago

I'm not sure tbh what's there to 'interpret' or how a compiler developer could misread that, the wording is quite clear.

ryao 2y ago
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.
- trealira 2y ago
  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.
  - ryao 2y ago
    This is not considering the document as a whole. I will defer to the GCC developers on what the document means on this.
    - trealira 2y ago
      I'm interested in hearing how considering the document as a whole leads to a different conclusion.
    - jcranmer 2y ago
      I am a member of the C standards committee, and I'm telling you you're wrong here. Martin Uecker is also member of the C standards committee, and has just responded to that bug saying that the comment you linked is wrong. I, and others here, have quoted literal standards text to you explaining why type punning through unions is well-defined behavior in C. I don't know who Andrew Pinski is, but they're factually incorrect regarding the legality of type punning via unions in C.
      - uecker 2y ago
        Andrew is a GCC developer who is very competent (much more than myself regarding GCC), but I think he was mistakenly assuming the C++ rules apply to C here as well.

nialv7 1y ago

I wouldn't be surprised if Andrew Pinski was just wrong. It's anecdotal but my impression of him isn't very good.