Re: The MOVE problem

"Doug Miller" <spambait@xxxxxxxxxx> wrote
"Judson McClendon" <judmc@xxxxxxxxxxxxx> wrote:
there wasn't ambiguity, I said there should not be any ambiguity,
and I stand by that. Anyone implementing a C compiler that gives any other
result than 3 is a nitwit or has a bug.

Sorry, but that's just incorrect. C does *not* define how the compiler is
supposed to behave in this instance.

Compiler writers may be confused about
this, but mathematics isn't. What pre and post ++/-- do is clearly defined in
C,

No, they're not -- when they're applied more than once to the same variable in
the same statement, the resulting behavior is explicitly UNdefined.

What they do individually is defined, and given that, mathematics is sufficient to
define how they should act collectively. That is my point. There is simply no
reason to have ambiguity here. Use of prefix and postfix ++/-- is common in C,
specifically to address the kinds of thing that's going on here. Only the fact that
the same variable is referenced more than once in the same expression makes
this an issue, and mathematical rules of evaluation order are sufficient to make
it unambiguous. Not realizing and utilizing this is the 'nitwit' aspect.

and all else in this example is pure mathematics, which should be THE FINAL
standard in evaluating an arithmetic expression. :-)

OK, fine:

i = 0;
i = ... let's evaluate this expression one step at a time:
i++ {i incremented to 1}
+ ++i {i incremented to 2, intermediate value so far is 1 + 2 = 3}
+ --i {i decremented to 1}
final value = 3 + 1 = 4

Pure mathematics. :-)

But wrong C, because C's postfix i++ is clearly defined is presenting a value for
evaluation *before* 'i' is incremented (in fact, that's the only reason to have both
prefix and postfix ++/--). No ambiguity there. :-)
--
Judson McClendon judmc@xxxxxxxxxxxxx (remove zero)
Sun Valley Systems http://sunvaley.com
"For God so loved the world that He gave His only begotten Son, that
whoever believes in Him should not perish but have everlasting life."


.

Relevant Pages

  • Re: The MOVE problem
    ... Anyone implementing a C compiler that gives any other ... Not realizing and utilizing this is the 'nitwit' aspect. ... evaluation *before* 'i' is incremented (in fact, that's the only reason to have both ... exactly which point the increment occurs -- and the behavior is explicitly ...
    (comp.lang.cobol)
  • Re: Question about compilation/evaluation environments
    ... >> This can't be done if the compilation and evaluation environments ... >> evaluation environment. ... All evaluations initiated by the compiler ... is being run in at macroexpand time, and if it is the compiler encountering ...
    (comp.lang.lisp)
  • Re: Atomic operations in 32 and 64 bit platforms
    ... a compiler to evaluate functions with fixed parameters in any order ... evaluation can involve loading values from memory, ... appear on the x86 stack, that is not defined by the C ...
    (comp.lang.asm.x86)
  • Re: Benefit of not defining the order of execution
    ... Even with a strict order of evaluation, the Rationale's "as if" rule would ... still give the compiler such provisions for optimization. ...
    (comp.lang.c)
  • Re: A C showstopper
    ... measured against the tradeoffs the language is ... order of evaluation was, and might think that the accidental ... choices of one's local compiler were definitive. ... greedy corporations, since it's easier to change the big corporation ...
    (comp.lang.c)