what is the right value about a = a++;

[Phil Carmody]

CSE elimination in C compilers is not rooted in unspecified evaluation order,
but in the freedom to optimize, so long as the externally visible behavior
agrees in some ways with the abstract behavior.

You don't have to evaluate a similar expression twice, if it makes no
difference (side-effect wise).

Then it's not "strict", it's "as if". But the word "strict" was explicitly
there above.

Phil
--

I'd argue that there is much evidence for the existence of a God.

Pics or it didn't happen.
-- Tom (/. uid 822)

 

[Shao Miller]

The following has to produce two x's, even now; though we don't know which
expression's x is printed first:

putchar('x') + putchar('x');

Doesn't that output a "bold 'x'" if they are evaluated simultaneously?

 

[Ike Naar]

Doesn't that output a "bold 'x'" if they are evaluated simultaneously?

Doesn't 6.5.2.2 p 10 forbid simultaneous evaluation?

6.5.2.2

10 There is a sequence point after the evaluations of the function
designator and the actual arguments but before the actual call.
Every evaluation in the calling function (including other function
calls) that is not otherwise specically sequenced before or after
the execution of the body of the called function is indeterminately
sequenced with respect to the execution of the called function. 94)

94)
In other words, function executions do not interleave with each other.

 

[Philip Lantz]

Doesn't 6.5.2.2 p 10 forbid simultaneous evaluation?

Doesn't anybody here understand a joke?

 

[lawrence.jones]

Doesn't 6.5.2.2 p 10 forbid simultaneous evaluation?

This started out as a joke, but there's an important point to be made
here. Note carefully 7.1.4p1:

Any function declared in a header may be additionally
implemented as a function-like macro defined in the header....
Any invocation of a library function that is implemented as a
macro shall expand to code that evaluates each of its arguments
exactly once, fully protected by parentheses where necessary, so
it is generally safe to use arbitrary expressions as
arguments.186)

186) Such macros might not contain the sequence points that the
corresponding function calls do.

So, although you're guaranteed that actual function calls aren't executed
simultaneously, there's no guarantee that library routines are actually
implemented as function calls unless you're careful to avoid any
potential macro version.

 

[Ike Naar]

This started out as a joke, but there's an important point to be made
here. Note carefully 7.1.4p1:

Any function declared in a header may be additionally
implemented as a function-like macro defined in the header....
Any invocation of a library function that is implemented as a
macro shall expand to code that evaluates each of its arguments
exactly once, fully protected by parentheses where necessary, so
it is generally safe to use arbitrary expressions as
arguments.186)

186) Such macros might not contain the sequence points that the
corresponding function calls do.

So, although you're guaranteed that actual function calls aren't executed
simultaneously, there's no guarantee that library routines are actually
implemented as function calls unless you're careful to avoid any
potential macro version.

Would parenthesizing the function name, as in

(putchar)('x') + (putchar)('x');

be sufficient to make sure the non-macro verion is used?

 

[Shao Miller]

Would parenthesizing the function name, as in

(putchar)('x') + (putchar)('x');

be sufficient to make sure the non-macro verion is used?

That's described in the same paragraph. Also described is #undef usage.