On 6/21/24 7:06 PM, olcott wrote:
...
Post by olcottWhen we assume the *= assigns
the result of the RHS * the LHS to the LHS
"x *= ++f * ++f"
means x = x * (++f * ++f)
thus cannot have implementation defined behavior.
You are correct about that conclusion, though I don't see what your
premise has to do with it. The expression ++f * ++f has, all by itself,
undefined behavior, independent of what larger expression it might be
part of. "implementation-defined behavior" is defined by the standard as
"behavior, for a well-formed program construct and correct data, that
depends on the implementation and that each implementation documents"
(3.13). Since this program is not well formed, implementations have no
obligation to document what it's behavior will be, so it cannot be
implementation-defined behavior.
Repeating what I said in an earlier message (with one minor correction):
"Except where noted, evaluations of operands of individual operators and
of subexpressions of individual expressions are unsequenced." (6.9.1p10)
Both ++f expressions are sub-expressions of the multiplication
expression. Thus, the executions are unsequenced, which is not, in
itself, a problem. However, they both have a side effect on the same
memory location, and that is a problem, because that same clause goes on
to say:
"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."
These two expressions are not potentially concurrent: they are in the
same expression, so they must be in the same thread, and if they are in
a signal handler, they must both be in the same signal handler.
Therefore, the expression ++f * ++f has undefined behavior.