Re: Regarding assignment to struct

On Sun 5/4/2025 6:48 AM, Tim Rentsch wrote:

>
One dark corner this feature has, is that in C (as opposed to C++) the
result of an assignment operator is an rvalue, which can easily lead
to some interesting consequences related to structs with arrays
inside.

 I'm curious to know what interesting consequences you mean here.  Do
you mean something other than cases that have undefined behavior?

I'm referring to the matter of the address identity of the resultant rvalue object. At first, "address identity of rvalue" might sound strange, but the standard says that there's indeed an object tied to such rvalue, and once we start applying array-to-pointer conversion (and use `[]` operator), lvalues and addresses quickly come into the picture.
The standard says in 6.2.4/8:
"A non-lvalue expression with structure or union type, where the structure or union contains a member with array type [...]
refers to an object with automatic storage duration and temporary lifetime. Its lifetime begins when the expression is evaluated and its initial value is the value of the expression. Its lifetime ends when the evaluation of the containing full expression ends. [...] Such an object need not have a unique address."
https://port70.net/~nsz/c/c11/n1570.html#6.2.4p8
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.
But is it, perhaps, intended to also allow such temporaries to have addresses identical to regular named objects? It is not immediately clear to me.
And when I make the following experiment with GCC and Clang
   #include <stdio.h>
   struct S { int a[10]; };
   int main()
   {
     struct S a, b = { 0 };
     int *pa, *pb, *pc;
     pa = &a.a[5];
     pb = &b.a[5];
     pc = &(a = b).a[5];
     printf("%p %p %p\n", pa, pb, pc);
   }
I consistently get the following output from GCC
   0x7fff73eb5544 0x7fff73eb5574 0x7fff73eb5544
And this is what I get from Clang
   0x7ffd2b8dbf44 0x7ffd2b8dbf14 0x7ffd2b8dbee4
As you can see, GCC apparently took C++-like approach to this situation. The returned "temporary" is not really a separate temporary at all, but actually `a` itself.
Meanwhile, in Clang all three pointers are different, i.e. Clang decided to actually create a separate temporary object for the result of the assignment.
I have a strong feeling that GCC's behavior is non-conforming. The last sentence of 6.2.4/8 is not supposed to permit "projecting" the resultant temporaries onto existing named objects. I could be wrong...
--
Best regards,
Andrey