Volatile MEMs in statement expressions and functions inlined astrees

[Paul Schlie]

Gentlemen,

This issue's resolution feels inappropriate, please consider the following:

It seems to be agreed that the value of assignment expression as an:

- lvalue, is equivalent to the lvalue of that assignment expression.
- rvalue, is equivalent to the rvalue of that assignment expression.

It further seems agreed that the terms "lvalue", and "rvalue" are semantic
terms, where: (please excuse my terminology, but intent should be clear)

- lvalue, refers to the "state-location" of a referenced "symbol" or
  "expression-value" (only symbols and expressions explicitly yielding
  reference-values are valid lvalues-expressions, no dereferencing of the
  resulting lvalue is implied or required).

- rvalue, refers to the "state-value" of the referenced symbol or
  "expression-value" (all valid expressions have valid state-values, and
  do imply (and require if volatile) dereferencing

The controversy appears to be related to if and/or when it is necessary, or
even appropriate to require the re-evaluation an assignment expression's
lvalue to derive it's rvalue when required for subsequent evaluation, and if
the semantics of an statement evaluation (which semantically yields no value
in C, unlike other languages such as scheme), implies the the semantics of
an <lvalue> or <rvalue> be applied to the enclosed root expression.

It is unreasonable to believe that the expression:

X = Y; :: X = Y, X;

Where if X were declared as volatile, would require X be sequentially
write-accessed, and then read-accessed, which seems clearly wrong; as it
would then be impossible to specify write-access to the exclusion of a
subsequent read-access of a volatile variable.

Therefore one of the following must be true to for volatile X:

X = Y; :: X = Y;

- the root statement-expression is treated as an <lvalue> evaluation, which
  does not imply or require the dereferencing of the resulting lvalue,
  therefore no terminal dereference of X.

- the root statement-expression is treated as an <rvalue> evaluation, where
  the resulting <rvalue> is thrown away, and assignment sub-expression's
  return "the value written", in the form of a temporary (or optionally by
  re-evaluating the lvalue target if non-volatile).

Therefore under no circumstances does:

(X = Y) :: (X = Y, X)

Except if X is non-volatile, and therefore can be re-de-referenced as an
optimization to an otherwise required intermediate temporary, therefore not
semantically equivalent.

In all circumstances:

(X = Y) :: (temp = Y, X = temp)

Regardless if X or Y are volatile, I have found no reference in the C
standard to support alternative fully constant conclusions.

-paul-