Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Users Search
Help Dashboard Sign In Sign Up
Q&A Code Reviews Meta
Q&A
Posts Tags Edits
Ask Question

Welcome to Software Development on Codidact!

Will you help us build our independent community of developers helping developers? We're small and trying to grow. We welcome questions about all aspects of software development, from design to code to QA and more. Got questions? Got answers? Got code you'd like someone to review? Please join us.

Post History

71%
+3 −0
Q&A Storing more bytes than a union member has, but less than the union size, with memcpy(3)

Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the cppreference page on...

posted 11mo ago by GrantMoyer‭  ·  edited 11mo ago by GrantMoyer‭

Answer
#9: Post edited by user avatar GrantMoyer‭ · 2023-06-09T00:23:15Z (11 months ago)
grammar
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is the maximum size of all it's members) not a `struct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is the maximum size of all its members) not a `struct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
#8: Post edited by user avatar GrantMoyer‭ · 2023-06-08T16:05:29Z (11 months ago)
typo
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is the maximum size of all it's members) not a `sruct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is the maximum size of all it's members) not a `struct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
#7: Post edited by user avatar GrantMoyer‭ · 2023-06-08T15:26:32Z (11 months ago)
typo
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is thr maximum size of all it's members) not a `sruct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is the maximum size of all it's members) not a `sruct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
#6: Post edited by user avatar GrantMoyer‭ · 2023-06-08T13:21:16Z (11 months ago)
simplify flow
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but the value of the extra bytes is unspecified, since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is thr maximum size of all it's members) not a `sruct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed since C99, but the value of the extra bytes is unspecified. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is thr maximum size of all it's members) not a `sruct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
#5: Post edited by user avatar GrantMoyer‭ · 2023-06-08T13:04:30Z (11 months ago)
comment on number of bytes copied
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but the value of the extra bytes is unspecified, since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but the value of the extra bytes is unspecified, since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • Also note that the implementation must not assume the destination of the memcpy is smaller than a `union u`. Consider the definition of memcpy:
  • > Copies count characters from the object pointed to by src to the object pointed to by dest. Both objects are interpreted as arrays of unsigned char.
  • Also consider that the object pointed to by dest is a `union u` (whos size is thr maximum size of all it's members) not a `sruct t`, even though it may be treated as a `struct t` in some cases.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
#4: Post edited by user avatar GrantMoyer‭ · 2023-06-08T12:49:58Z (11 months ago)
Add note about GCC behavior
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but implementation defined, since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • [1]: https://en.cppreference.com/w/c/language/union
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but the value of the extra bytes is unspecified, since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • Since the value of the bytes is unspecified, the implementation may use any value in any instace, and does not need to document the behavior. That said, [GCC *does* document this behavior][2] (and clang tries to follow GCC's implementation defined behavior on Linux):
  • > The relevant bytes of the representation of the [union] object are treated as an object of the type used for the access.
  • [1]: https://en.cppreference.com/w/c/language/union
  • [2]: https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html
#3: Post edited by user avatar GrantMoyer‭ · 2023-06-08T12:39:52Z (11 months ago)
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but implementation defined since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • [1]: https://en.cppreference.com/w/c/language/union
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but implementation defined, since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • [1]: https://en.cppreference.com/w/c/language/union
#2: Post edited by user avatar GrantMoyer‭ · 2023-06-08T12:39:30Z (11 months ago)
  • This behavior is explicityly allowed, but implementation defined since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • [1]: https://en.cppreference.com/w/c/language/union
  • Reading from a union member who's size is larger than that of the last written member is explicitly allowed, but implementation defined since C99. From the [cppreference page on C unions][1]:
  • > If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.
  • [1]: https://en.cppreference.com/w/c/language/union
#1: Initial revision by user avatar GrantMoyer‭ · 2023-06-08T12:38:12Z (11 months ago) 
This behavior is explicityly allowed, but implementation defined since C99. From the [cppreference page on C unions][1]:

> If the size of the new type is larger than the size of the last-written type, the contents of the excess bytes are unspecified (and may be a trap representation). Before C99 TC3 (DR 283) this behaviour was undefined, but commonly implemented this way.

[1]: https://en.cppreference.com/w/c/language/union