{"id":1270,"date":"2022-08-30T15:15:08","date_gmt":"2022-08-30T15:15:08","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2013\/11\/10\/union-for-uint32_t-and-uint8_t4-undefined-behavior-collection-of-common-programming-errors\/"},"modified":"2022-08-30T15:15:08","modified_gmt":"2022-08-30T15:15:08","slug":"union-for-uint32_t-and-uint8_t4-undefined-behavior-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2022\/08\/30\/union-for-uint32_t-and-uint8_t4-undefined-behavior-collection-of-common-programming-errors\/","title":{"rendered":"union for uint32_t and uint8_t[4] undefined behavior?-Collection of common programming errors"},"content":{"rendered":"

[edit: read my edited section below, as I’m now unsure of whether this is undefined behavior or not; I’ll leave the majority of my answer the same, however, until I can confirm further] Yes, this is undefined behavior. The C++ Standard, section 9.5.1, states:<\/p>\n

\n

In a union, at most one of the non-static data members can be active at any time, that is, the value of at most one of the non-static data members can be stored in a union at any time. [ Note: One special guarantee is made in order to simplify the use of unions: If a standard-layout union contains several standard-layout structs that share a common initial sequence (9.2), and if an object of this standard-layout union type contains one of the standard-layout structs, it is permitted to inspect the common initial sequence of any of standard-layout struct members; see 9.2. \u2014 end note ]<\/p>\n<\/blockquote>\n

This means that only the most recently written to member can validly be read from as well (reading from the others is technically undefined behavior). Only one<\/em> member of the union can be active at any time. Not two.<\/p>\n

You might ask why? Consider your example. C++ does not mandate the endianness of addr32<\/code>. It could be big-endian, little-endian, or middle-endian. If you write to addr8<\/code>, and then read from addr32<\/code>, C++ cannot guarantee you’ll get the right value out because of the endianness in this case. One one computer, it could be one value, and on another, it could be a different value. Hence, doing so (that is, writing to one member and reading a different one) is undefined behavior.<\/p>\n

Edit:<\/strong> For those wondering what “active” means, the MSDN documentation on Unions states:<\/p>\n

\n

The active member of a union is the one whose value was most recently set, and only that member has a valid value.<\/p>\n<\/blockquote>\n

Edit Edit:<\/strong> I had always thought the behavior of doing this was undefined, but now I’m not so sure after R. Martinho Fernandes’s comments and answer and after re-reading the quote from MSDN. The value is certainly unspecified\/undefined, but now I’m not so sure if the behavior is (undefined value means you might get different results back; undefined behavior means your system might crash, the two being different things). I’m going to consider this further and talk with others I know to see if I can find a more explicit answer.<\/p>\n

I do think it’s safe to say, however, that in general reading an inactive member in a union can<\/em> be undefined behavior (except for the special note in the Standard, of course), but I don’t know if it always<\/em> is (i.e. there may be some exceptions beyond the special note in the section of the C++ Standard I’ve quoted).<\/p>\n

Originally posted 2013-11-10 00:13:25. <\/small><\/p>","protected":false},"excerpt":{"rendered":"

[edit: read my edited section below, as I’m now unsure of whether this is undefined behavior or not; I’ll leave the majority of my answer the same, however, until I can confirm further] Yes, this is undefined behavior. The C++ Standard, section 9.5.1, states: In a union, at most one of the non-static data members […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-1270","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1270","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=1270"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/1270\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=1270"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=1270"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=1270"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}