Date: Sun, 10 Nov 2024 20:05:41 -0500
On Sun, Nov 10, 2024 at 6:04 PM Brian Bi via Std-Discussion
<std-discussion_at_[hidden]> wrote:
> Unless I've misunderstood, the C23 draft appears to say that as soon as you write to any member of a struct, all padding bits are reset to unspecified values.
>
> 6.2.6.1/6: When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values [...]
>
> That seems to prevent the use of `memcmp` for comparing the values of struct objects in most cases.
>
> Or is the C standard only talking about writes of struct type? (Which, as you probably know, don't exist in C++: an assignment operator, possibly a trivial one, is always called.)
The question is, does "When a value is stored ... including in a
member object" mean, "When a value is stored in an object, or in any
object that is a member of that object", or "When a value is stored in
an object, which may just happen to be a member of some other object"?
I'd be inclined toward the latter (i.e., it only applies to padding
within writes of struct type), since otherwise 6.2.6.1/7 would be
totally redundant, and it would also cause silly things like data
races if you memcmp() one member while concurrently writing another
member a mile away. But a "compiler writers should be given as many
liberties as possible" enthusiast would be inclined toward the former.
N691, which introduced the clause, was primarily concerned with writes
of struct type. It was listed in N2013 as having an unclear meaning
(see Q60-Q72), but it looks like no one in WG14 discussed it much
further. (Too bad wording cleanups are much less shiny than new
features...) Gustedt interpreted it in N2159 as meaning "any object
that is a member", but the minutes are very vague in the N2187
minutes, and there don't seem to be any other WG14 interpretations
about it. In practice, the big compilers don't write into padding on
member writes since they're deathly afraid of data races on any level
of the IR.
Matthew House
<std-discussion_at_[hidden]> wrote:
> Unless I've misunderstood, the C23 draft appears to say that as soon as you write to any member of a struct, all padding bits are reset to unspecified values.
>
> 6.2.6.1/6: When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values [...]
>
> That seems to prevent the use of `memcmp` for comparing the values of struct objects in most cases.
>
> Or is the C standard only talking about writes of struct type? (Which, as you probably know, don't exist in C++: an assignment operator, possibly a trivial one, is always called.)
The question is, does "When a value is stored ... including in a
member object" mean, "When a value is stored in an object, or in any
object that is a member of that object", or "When a value is stored in
an object, which may just happen to be a member of some other object"?
I'd be inclined toward the latter (i.e., it only applies to padding
within writes of struct type), since otherwise 6.2.6.1/7 would be
totally redundant, and it would also cause silly things like data
races if you memcmp() one member while concurrently writing another
member a mile away. But a "compiler writers should be given as many
liberties as possible" enthusiast would be inclined toward the former.
N691, which introduced the clause, was primarily concerned with writes
of struct type. It was listed in N2013 as having an unclear meaning
(see Q60-Q72), but it looks like no one in WG14 discussed it much
further. (Too bad wording cleanups are much less shiny than new
features...) Gustedt interpreted it in N2159 as meaning "any object
that is a member", but the minutes are very vague in the N2187
minutes, and there don't seem to be any other WG14 interpretations
about it. In practice, the big compilers don't write into padding on
member writes since they're deathly afraid of data races on any level
of the IR.
Matthew House
Received on 2024-11-11 01:05:53