Re: Regarding assignment to struct

Andrey Tarasevich <noone@noone.net> writes:

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.

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.

Though I can imagine the possibility of code that modifies `a` and
reads via `pc` within the same full expression.  Perhaps a compiler
would refrain from optimizing the storage if `a` and `*pc` overlap.
I'm too lazy at the moment to write a demo.

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).

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