Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <Keith.S.Thompson+u@gmail.com>
Newsgroups: comp.lang.c
Subject: Re: Regarding assignment to struct
Date: Sun, 04 May 2025 13:20:10 -0700
Organization: None to speak of
Lines: 59
Message-ID: <87bjs8p1qd.fsf@nosuchdomain.example.com>
References: <vv338b$16oam$1@dont-email.me> <vv4j9p$33vhj$1@dont-email.me> <vv66cu$hbtf$1@dont-email.me> <87ikmhp5x3.fsf@nosuchdomain.example.com> <vv6ng8$1410m$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain
Injection-Date: Sun, 04 May 2025 22:20:13 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="ed5558e6b5362a41777eb3e1b4d62403"; logging-data="2864406"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX189Mdv84sMwVa9v81D1rf9H"
User-Agent: Gnus/5.13 (Gnus v5.13)
Cancel-Lock: sha1:ZuqSttWYIW3k91aRobGdNP4VQ50= sha1:ZLyZ0Sz4AjGHxV0UEMbn7nlv174=
Xref: csiph.com comp.lang.c:393149

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 bytes are bytes within a structure or union that are not part of
any member.  Padding *bits* are bits within the representation of an
integer type that do not convert to an object's value.  I believe it's
true that integer padding bits need not be copied by assignment (for
example, they might be normalized to 0 for some reason), but that's
not specific to struct or union assignment.

There can also be bits within a struct or union representation that are
adjacent to a bit-field and do not contribute to any value.  As far as I
know, there's no name for those bits.

[snip]

>> Finally, why would you care?
>
> The fact that an implementation does not have to do the equivalent of
> memcpy() to perform a struct copy means that successful assignment
> cannot be checked by using memcmp().

Are you referring to checking whether an assignment was performed
or not, due to uncertainty about what the program has done?  If you
mean doing an assignment and then checking whether it succeeded,
I can't think of a context where that makes sense.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */