Consider

p = p++;

It's bad code, of course. It's the wrong way to just increment p.

The problem occurs when you encounter it in a modally large, and modally hard-to-maintain C program, and you must predict how it will work.

The obvious answer is wrong: it is that since assignment considered as another binary operator has lower precedence than the prefix increment or decrement, then the ++ happens before the assignment, and the above code sets p to p+1.

However, the industry-highjacked effort to "standardize" an essentially idiomatic and for this reason not truly standardizable language has apparently ripped computer science a new asshole.

A whole theory, unique to this effort, of "sync points" was developed, it appears to me, to allow compiler developers to store the incremented value of p at any time prior to the sync point, here, at the end of evaluation.

This makes sense, but only from the standpoint of highly optimized platforms where the post and pre increment/decrement family of operators are seen, from the standpoint of raw speed, to be party poopers.

They require the system to access memory whereas most of the other operators stay on the stack.

So what's the problem?

The problem is that once again, the crime of making "efficiency" (which is actually just blind speed anytime you cannot immediately express efficiency as a ratio of effort expended to goals accomplished) has messed up an already messed up language.

The programmer who properly reasons in terms of a simple stack machine model of runtime is penalized in favor of indeterminacy!

This appears to have happened to Herb Schildt, who based his books on C on theory and practice, but did not test all of his examples on non-Microsoft platforms.

"Knowledge" isn't knowledge when it is memorizing a standard which says that mere programmers may not know, in general, how pathological examples of C code (which may well occur in the real world, whether as hand coded code, or generated from any one of the thousands of C code generators that exist).

Industrial rationalization, however, is precisely this removal of the knowing ability from mere mortals.

And note that if you "try it out" on your platform you have learned nothing, since your platform, if standard, is not bound day to day to give the same result.

But that's been going on for a long time. In the mainframe era, I met "expert" PL/I programmers who could not tell you if the right hand side of a PL/I OR was evaluated when the left hand side was true, and whose "expertise" was consituted in a willingness to work terribly hard with no back-talk.

And, the sort of theory and practice Herb derived was even then considered louche, if useful in a pinch; ignorance was even then a form of strength.

The ugly automobile metaphor was then and is now popular: "when I drive my car I don't care about what goes on under the hood", which even from the mere standpoint of safe, environmentally aware and responsible driving, is nonsense.

But even then any contrarian view is shouted down by people who'd rather memorize the rules of ignorance than do theory and practise in an integrated, truly rational if not industrially rationalized, way. The most recent example was the vandalism that occured to my comments on comp.programming on usenet.

I really need to stay out of usenet, an expense of spirit in a waste of shame. I get addicted to all the attention, most of it extremely unfavorable because I insist on being a subject and not an object.