I just traced a problem with using the decrement operator in a loop which is dependent upon the version of gcc with which you compile the code. WIth the SAFE_VERSION constant definition set to "1" the loop works as expected with gcc 4.3.0:

Producing the output:

What I would have expected would be that the right-hand side expression would be evaluated, assigned to the value for the pointer on the left-hand side then the pointer position would be decremented.

This did not work with gcc version 4.8.3 which produces the following output:

Is this something that I should have known or is it new weirdness in the compiler?

p-- decrements the pointer, *p-- decrements the value it points to
afaik

The problem is in your code. The evaluation order of assignments (= and ++) isn't defined by any standard; it is called 'Undefined behaviour'. Another (anti-)example:

Look at any C or C++ reference, such as
http://en.cppreference.com/w/c/langu...tor_precedence

Notice where is says "right to left" associativity for group 2 in that table.

I hope it is obvious what that means.

That expectation is your mistake. As NevemTeve said, the sequence is not defined.

There are few and specific constructs in C and C++ for which sequence is defined. The ; ending a statement is the most common/important of those. But otherwise sequence is generally undefined, so when you make any "this happens then that happens" assumptions without a defined sequence point, your code is likely to work by accident rather than by design and then likely to bite you later. In other words what you saw as gcc version "new weirdness" is really your own old bug.

I think that is an example of a different and fundamentally more serious kind of undefined behavior. Another language rule is being violated there beyond the violation of assuming sequence without a sequence point. If it were merely a sequence violation than we we expect b to end up as 7, 8 or 9 and a to end up as 5. But real (not just theoretical "undefined means anything might explode") compilers may give not only results other than 7, 8 or 9 for b and even results other than 5 for a. Regardless of the sequence, a was incremented twice and if you don't know the real rules of the language, you would expect it to reach 5 (and b to be 7 to 9) depending on which order the steps occur in.

thx, never have done such a thing

anyway, this is interesting to me so il lay it out
an equation is variable = expression
but there is an operation on the variable and the variable is used to calculate the expression
so to deconstruct

variable
--------------
p = p--;
value pointed to by p
--------------

expression
--------------
p - DELAY;
value pointed to by result
--------------

according to the table
-- is done first
- second
= third

but... p-DELAY is in parentheses so math says it has to be done before any other operation on it's variables
so (p-DELAY) becomes a different value to what p-DELAY could give

just some thoughts..

No, that is the precedence according to which the operators bind. It says absolutely nothing about the sequence in which the operations are performed beyond the obvious requirement that an operation cannot be performed before the values of its operands have been determined. Even for a simpleit is entirely possible that the first action taken is to increment variable b as long as the original value is remembered for use in the expression. (No, I don't know of a machine architecture for which that would be reasonable, but there is nothing in the language that would preclude such a sequence.)

Further down in that page is a link to an "Order of evaluation" page, with some notes on undefined behavior that are relevant.

Since I was commenting (at that moment) on genss's incorrect post, rather than the original question, and I have been programming for so long, I did not even think of the potential for someone less experienced to interpret an operator precedence table other than as you just said.

But now that you said it so clearly for people who already knew it, we are stuck with the problem that people who didn't already know the above also don't know what "bind" means in the above context.

I'm don't know how I could both accurately and clearly describe what "bind" means. But the effect is very similar to wrapping () around the operator and its nearest possible operands.

so p = p - p--;
when we "bind" the -- first we have p = p - (p--);
and when we bind the - second we have p = (p - (p--));

In the original *p-- when we bind "right to left" we get *(p--) and then (*(p--))

That is not exactly what "bind" means and you can find cases in C where the extra () implied by a method that crude would mean something else. But to a first level of understanding that is the best definition of "bind" I have.

And as you said more clearly, once you've done all that binding, you still haven't determined much about the execution sequence.

We know from the binding that the -- applies to p and not to *p, but we don't know whether the memory read operation specified by the * happens before or after the subtract or memory write operations specified by the --

Even in *--p we can know that computing the decremented value happens before the memory read specified by the *, but we still don't know that storing that value back into the variable p happens before that read, and we don't know that the decremented value is computed only once. It might be before and after the *.

The compiled code might well optimize the value of --p by knowing it is &p, but put in a later decrement operation for the side effect of --p. So we replace the first byte of p with 'B' and then decrement p. On an LSB machine the net operation replaces the low byte of p with 'A'. (But of course that is not the most likely behavior).

This is the kind of "undefined" operation where a theoretical standard compliant compiler could replace the whole line with code to reformat your hard drive, and even a real compiler may generate code well outside the range of possibilities expected by a naive programmer.

y my bad, this increment+assign is new to me
i even put it into 2 groups before saying that

why even allow increment before equal sign if the variable is used after the equal sign ?
p++;
*p=*(p-DELAY);
would not be prone to interpretation
maybe a cc warning would be nice ?

Hi,

Thanks for all the replies. I am happy just to have traced the problem. Not having studied compilers extensively I must say all this talk of sequences has my head spinning.

In the "Order of evaulation" reference given by rknicols http://http://en.cppreference.com/w/...age/eval_order rule number 6 states:

By my limited understanding, does this not correspond with my expectation in my original post?

Once again I appreciate your discussing this with me.

I'm having trouble wrapping my head around any necessity of even saying the above. I guess the standards authors saw some ambiguity that I don't see.

I think you may be missing the narrowness of the meanings of "value" and "side-effect" in that quote, in thinking that says something significant about sequencing, rather than simply being the meaning that postincrement or postdecrement always had.

No, it does not.

That rule kind-of says the value of the p (in the --p) on the left of your statement is computed before it is changed by the --.

That rule says nothing about whether another instance of p on the right hand side is computed before or after that --.

Sequence points aren't a compiler issue - it's a C language issue.

In to my reading of this the only sequence point is the ';' and the DELAY will be subtracted from from the address of p, the value there will be dereferenced and assigned as the value of p and the pointer will then be decremented. Since p itself is not being being altered in the assignment statement this is well defined - up until the point you begin assigning a value to the locations that precede p. At that point all bets are off - and this is what you're doing.

No points for style either.

should i file a gcc bugreport for a warning ?
"request for "undefined evaluation order" warning" ?

anyway,
thx to johnsfine and rknichols

Actually on more careful inspection the math is right.

The sequence point rule is: between consecutive "sequence points" an object's value can be modified only once by an expression.

It's the unsequenced access here that is the issue. The value of p is potentially changed by p-- then accessed before hitting the sequence point (the end of the expression).

Apologies for muddying the waters. *

*This is why I never write code remotely like that. To easy to get something wrong.

---------- Post added 12-04-14 at 01:50 PM ----------

Did you use -Wall as a switch? You will get a warning.

Both gcc (-Wall) and clang (-Weverything) would have warned that the operations are unsequenced.

EDIT: Got beat to it.

Thanks for the timely reminder to use the -Wall flag, and now I will know what the warning means.