Re: Regarding assignment to struct

scott@slp53.sl.home (Scott Lurndal) writes:

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>

James Kuyper <jameskuyper@alumni.caltech.edu> writes:
>

On 5/3/25 20:37, Keith Thompson wrote:
>

Lawrence D'Oliveiro <ldo@nz.invalid> writes:
>

On Sat, 3 May 2025 01:14:46 -0700, Andrey Tarasevich wrote:
>

Virtually every C project relies on assignment of structures.
Passing-returning structs by value might be more rare (although
perfectly valid and often appropriate too), but assignment...
assignment is used by everyone everywhere without even giving
it a second thought.

>
There is a caveat, to do with alignment padding:  will this
always have a defined value?

>
I don't believe so.  In a quick look, I don't see anything in
the standard that explicitly addresses this, but I believe that a
conforming implementation could implement structure assignment by
copying the individual members, leaving any padding in the target
undefined.

>
"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.56)" (6.2.6.1p6).
>
That refers to footnote 56, which says "Thus, for example,
structure assignment need not copy any padding bits."

>
Yes, that's what I missed.
>
It's interesting that the footnote refers to padding *bits* rather
than padding *bytes*.  I presume this was unintentional.

>
Padding bits:
>
        struct A {
            uint64_t    tlen  : 16,
                              : 20,
                        pkind :  6,
                        fsz   :  6,
                        gsz   : 14,
                        g     :  1,
                        ptp   :  1;
        } s;
>
There are 20 padding bits in this declaration.  Perhaps that's
what they're referring to?

To me it seems clear that the "padding bits" here is meant to refer
to all of the following:

   unoccupied bytes between members, due to member alignment
   unoccupied bytes at the end of a structure or union
   bits corresponding to unnamed bit-field members
   unoccupied bits or bytes caused by explicit bit-field alignment
   unoccupied bits or bytes caused by other bit-field alignment

Any member objects may have their own internal padding bits.  Any
assignment of a struct or union follows the usual rule that any
padding bits that are part of a target member have unspecified
values (as long as the member doesn't become a trap representation
as a result).

Considering all these parts together, I think it makes sense to say
that the padding bits of an object are those bits that do not
participate in determining the abstract value of the object (not
counting that some combination of padding bits might cause the
object to become a trap representation, which never happens for
structs or unions).

(Yes I know that the term "trap representation" has been changed in
later versions of the C standard.  Please make any needed editorial
changes internally, without having to post a followup.)