C compiler implements wrong semantics

[John Mackin]

I originally wrote the following as a piece of mail to the
poster of the article, but then I thought someone might
be led to believe some of the hideous misstatements
he made, so I am following-up instead...

In article <2147 at brl-tgr.ARPA>
	NEVILLE%umass-cs.csnet at csnet-relay.arpa (Neville D. Newman) writes:

> While digging through the guts of the portable C compiler, i noticed
> that it produced exactly the same code for two statements that i think
> have different semantics.

> According to my C references, the unary
> operators have precedence over binary operators (and are evaluated right
> to left).

First problem.  ``my C references'', ``my books'' (below): what are
these meaningless terms?  WHAT are you using as a reference?  There
is only ONE book that should be referred to in a case like this:
``The C Programming Language,'' by Brian W. Kernighan and Dennis
M. Ritchie, Prentice-Hall, 1981, commonly referred to as ``K&R''.
That is the document that defines the language, at least until the
ANSI C standard is produced; and even then there will be ANSI C and K&R
C, unless I miss my guess.  If you are digging around in the internals
of a C compiler and you haven't read K&R until you more or less know
it by heart, go do so, and you don't need to read any more of this
news item.  If I seem to be belaboring the obvious, the reason will become
clear very soon.

> The rule for pre- and post-increment (and -decrement) operators
> is, of course, that a++ changes the value of  a  after the value of the
> term is used, so that the change is a side-effect.

Correct.  Read what you wrote ... ``IS A SIDE-EFFECT.''  Remember
those words, we'll have cause to refer to them shortly.

> ++a, on the other
> hand changes the value of  a  before the term is used and is therefore
> entirely equivalent to  (a += 1) or (a = a+1).

If by this you are trying to claim that the change to a in this case is
NOT a side-effect, you're wrong.  A side-effect is a change to a
variable ``as a by-product of the evaluation of an expression'':
K&R, page 50.

> According to my books, if a is 5, then (a++ + a) ought to evaluate to 11.

WHAT BOOKS?  Any book which implies or states any such thing is just
plain WRONG!  Read K&R, page 50 (Section 2.12):

	In any expression involving SIDE EFFECTS, there
	can be subtle dependencies on the order in which
	variables taking part in the expression are stored.
	[Emphasis mine.]

I won't quote it at greater length, it'd be too much to type, but they
make it perfectly clear.  What that expression ``ought to evaluate to''
is NOT DEFINED.  The implementer of a given C compiler is free to evaluate
it as they wish.  Even lint knows that; applying it to your test program gives:

xx.c(9): warning: a evaluation order undefined
xx.c(12): warning: a evaluation order undefined
xx.c(15): warning: a evaluation order undefined
xx.c(18): warning: a evaluation order undefined
xx.c(23): warning: a evaluation order undefined
xx.c(26): warning: a evaluation order undefined
xx.c(29): warning: a evaluation order undefined
xx.c(32): warning: a evaluation order undefined

> So the questions for the day are:  Is pcc "right" because it is sort of the
> defacto standard?  (i have a friend who claims that BNF and such are useless,
> the compiler is the only definition of a language that counts)

There are cases, particularly with reference to the cpp, where this
argument is valid.  However, in this case it doesn't enter into
the discussion, because the result is NOT DEFINED.

> Is this
> discrepancy between Unix C's behaviour and description already widely known
> and carefully worked around?

There IS no discrepancy.

> Should i attempt to fix it and possibly break
> some code or leave it alone for old time's sake?

Like the old adage says: ``If it's not broken, DON'T fix it.''

> The pre-increments should be give results of 12 on all systems,
> or else there's a *bad* problem.

INCORRECT!  The order of evaluation of such things IS NOT DEFINED!

I'm sorry if I've been a bit over-vehement about this, but it
does upset me when people don't read the documents in the case...

John Mackin, Basser Department of Computer Science,
	     University of Sydney, Sydney, Australia

{seismo,ukc,mcvax,ubc-vision,prlb2}!munnari!basser.oz!john
john%basser.oz at SEISMO.CSS.GOV
CSNET: john at basser.oz