Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Regarding assignment to struct Date: Mon, 05 May 2025 01:26:12 -0700 Organization: None to speak of Lines: 61 Message-ID: <87seljh3a3.fsf@nosuchdomain.example.com> References: <86plgo7ahu.fsf@linuxsc.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Date: Mon, 05 May 2025 10:26:20 +0200 (CEST) Injection-Info: dont-email.me; posting-host="ce0368853eba606cbaed4ff885db219e"; logging-data="99403"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18u12Jj0YRDWok8Ahzzomle" User-Agent: Gnus/5.13 (Gnus v5.13) Cancel-Lock: sha1:kVVdBzXE5USvnYV+xajm7cyXn/o= sha1:F3c3L9AM5VBJVk4SVe72NfXLF48= Xref: csiph.com comp.lang.c:393164 Andrey Tarasevich 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 */