Path: news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Regarding assignment to struct Date: Mon, 05 May 2025 21:57:47 -0700 Organization: A noiseless patient Spider Lines: 80 Message-ID: <86v7qe2v5g.fsf@linuxsc.com> References: <87ikmhp5x3.fsf@nosuchdomain.example.com> <87bjs8p1qd.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Date: Tue, 06 May 2025 06:57:53 +0200 (CEST) Injection-Info: dont-email.me; posting-host="f84420402be78ce51ba0e8f0077f27e2"; logging-data="2337910"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1//FkE40clzRgtz+v8Qe9ucaje2hAQIsoI=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:qEwY4+rJEmiPzF0WuEN4PvJhNmI= sha1:nkcvioFlhTPRjbkSEI5IyrU2kHo= scott@slp53.sl.home (Scott Lurndal) writes: > Keith Thompson writes: > >> James Kuyper writes: >> >>> On 5/3/25 20:37, Keith Thompson wrote: >>> >>>> Lawrence D'Oliveiro 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.)