Path: utzoo!attcan!uunet!wuarchive!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!news-server.csri.toronto.edu!csri.toronto.edu!norvell
From: norvell@csri.toronto.edu (Theo Norvell)
Newsgroups: comp.lang.misc
Subject: Re: := versus ==  (Really side effects in C)
Message-ID: <1990Aug2.160747.11796@jarvis.csri.toronto.edu>
Date: 2 Aug 90 20:07:47 GMT
References: <=L-4T-A@ggpc2.ferranti.com> <17559:Aug101:50:5290@kramden.acf.nyu.edu> <7H+4AM6@xds13.ferranti.com> <1990Aug2.170110.28208@rice.edu>
Organization: CSRI, University of Toronto
Lines: 32

In article <1990Aug2.170110.28208@rice.edu> Preston writes:
>
>Normally, we say: 
>
>	x + y = y + x	where x and y are arbitrary expressions.
>
>With C, Q, and PL/M, this doesn't hold.
>E.g.,
>
>	(i := 1) + i is not always equal to i + (i := 1)
>
>Same problems with ++ and -- in C.
>Same problem in lots of languages where people write functions
>with side-effects.

I can't speak for Q or PL/M, but in C this not so.  The order of evaluation
is not specified for the + operator, nor most others (including the assignment
operators). Given arbitrary expressions x and y, (x + y) can be evaluated by
evaluating x first and then y or the other way around and then adding.

Furthermore, the ansi standard makes it clear that when an expression contains
two assignments to the same variable or an assignment and a reference (unless,
of course, the value to be stored depends on the reference), with no intervening
sequence point, the result is not merely one or the other possible result
but entirely undefined.  So in C the expressions
	(i = 1) + i
and
	i = 1 + ++i
are quite undefined.  A correct C implementation could launch a nuclear strike
on 24 Sussex Drive upon evaluating such an expression (whether it does or not
is a ``quality of implementation'' issue). Just because you see such expressions
in other peoples code does not mean they are allowed by the language.