Re: Regarding assignment to struct

On Mon 5/5/2025 1:26 AM, Keith Thompson wrote:

>
I wondering what the last sentence is intended to mean ("... need not
have a unique address"). At the first sight, the intent seems to be
obvious: it simply says that such temporary objects might repeatedly
appear (and disappear) at the same location in storage, which is a
natural thing to expect.

 You snipped this: "Any attempt to modify an object with temporary
lifetime results in undefined behavior.".  Which means, I think,
that an implementation that shared storage for "such an object"
with something else probably isn't going to cause problems for any
code with defined behavior.

It is going to cause problems, if the code relies on the address identity of the object, assuming the standard intends to provide such guarantees.

Though I can imagine the possibility of code that modifies `a` and
reads via `pc` within the same full expression. 

That's easy (in the context of declarations from my previous example):
   pc = &(a = b).a[5], a.a[5] = 42, printf("%d\n", *pc);
As one would expect, this produces different output in GCC and Clang for the reasons I already described.

But unless I've somehow missed it, the "Such an object need not
have a unique address." wording doesn't appear on that web page or
in my copy of n1570.pdf.  C17 does add these two sentences:
      An object with temporary lifetime behaves as if it were declared
     with the type of its value for the purposes of effective type. Such
     an object need not have a unique address.
 Normally any two objects with overlapping lifetime must have distinct
addresses.  This addition, I think, gives compilers permission to have
temporary lifetime objects overlap with other existing objects, but not
to have a modification to one object affect the value of the other
(unless the modification invokes UB, of course).

If so, that would be extremely underspecified. A mere "such an object need not have a unique address" is insufficient to fully convey the permission to overlap existing named objects. And that's probably what led to difference in interpretation between GCC and Clang.
Modification of the temporary is "prohibited" (as UB), but modification of the overlapped named object is not. The consequences can be quite surprising.
--
Best regards,
Andrey