Sujet : Re: Regarding assignment to struct
De : jameskuyper (at) *nospam* alumni.caltech.edu (James Kuyper)
Groupes : comp.lang.cDate : 05. May 2025, 02:08:43
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <vv932r$37tbq$1@dont-email.me>
References : 1 2 3 4 5 6
User-Agent : Mozilla Thunderbird
On 5/4/25 16:20, Keith Thompson wrote:
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
On 5/3/25 20:37, Keith Thompson wrote:
...
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.
...
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.
Sorry, I didn't explain what I was thinking about in any detail. I've
seen code that allows a data structure to be modified by one section of
the code, and then periodically checks each object in that data
structure (including aggregate objects) to see whether it has been
modified by using memcmp() versus a saved copy. If so, it updated the
saved copy, including a timestamp when it was updated. If it weren't for
the need to keep track of the timestamp, it would always be simpler, and
not much slower, to always replace the saved copy, whether or not
there'd been a change.
I should have made it clear that I basically understand and agree with
your "why would you care" criticism. But it's part of my nature to look
for the edge cases where differences that ordinarily don't matter, could
matter.