Path: csiph.com!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c++
Subject: Re: is "x *= ++f * ++f" a valid statement ?
Date: Tue, 23 Jul 2024 07:32:56 -0700
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <86plr441rb.fsf@linuxsc.com>
References: <v2nivh$1pl7o$1@raubtier-asyl.eternal-september.org> <96127c8d8d204b7c3230828101bc2b6e@www.novabbs.org> <v7n2mj$t6tp$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Tue, 23 Jul 2024 16:32:56 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="7d13b34d8c99e76fe2e42ca3bbf07909"; logging-data="1304783"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+AIiUzrHoRCK3X8Vu0Hj/nuUw1sMZejcM="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:KtKx4PkLjQpsQkHk5N/BoAgY+3I= sha1:btwXYAQLbaqd4TYNhdke46Huq5U=
Xref: csiph.com comp.lang.c++:119729

James Kuyper <jameskuyper@alumni.caltech.edu> writes:

> On 7/22/24 13:51, testuseri2p wrote:
>
>> I'd say in simple words, if you alter a variable multiple times in
>> one statement, you get UB.
>
> The correct (and admittedly more complicated) statement of the
> relevant rule is:

> "If a side effect on a memory location (6.7.1) is unsequenced
> relative to either another side effect on the same memory location
> or a value computation using the value of any object in the same
> memory location, and they are not potentially concurrent (6.9.2),
> the behavior is undefined."
>
> The biggest difference between the exact rule and what you said is
> that two different updates to a variable may occur in the same
> statement, so long as they are sequenced relative to each other.
> Sub-expressions of an expression are sequenced before evaluation of
> the expression itself.  In general, the sub-expressions of a
> expression are unsequenced, but there several exceptions: ||, &&,
> ?:, the comma operator.

Don't forget << (and also >>?).

> A minor detail is that a variable must be declared, whereas memory
> locations can, for instance, be part of allocated memory for which
> no declaration exists - it is still undefined behavior to write code
> that applies unsequence side-effects to such memory locations.

The original statement most likely meant "variable" as a stand-in
for "object".