Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site wvlpdp
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxn!ihnp4!inuxc!pur-ee!uiucdcs!convex!wvlpdp!john
From: john@wvlpdp
Newsgroups: net.lang.c
Subject: Re: *p++ = *p and more
Message-ID: <3400001@wvlpdp>
Date: Thu, 17-Apr-86 11:26:00 EST
Article-I.D.: wvlpdp.3400001
Posted: Thu Apr 17 11:26:00 1986
Date-Received: Mon, 21-Apr-86 04:49:14 EST
References: <357@g.cs.cmu.edu>
Lines: 25
Nf-ID: #R:g.cs.cmu.edu:357:wvlpdp:3400001:000:1171
Nf-From: wvlpdp!john    Apr 17 10:26:00 1986



	K & R says on the last page (50) of Chapter 2.

	Function calls, nested assignment statements and increments and
	decrement operators cause "side effects" - some variable is changed
	as a byproduct of the evaluation.   In any expression involving side
	effects, there can be subtle dependencies on the order in which
	variables taking part in the expression are stored.  One unhappy
	situation is typified by the statement:

		a[i] = i++;

	The question is whether the subscript is the old value of i or the new.
	The compiler can do this in different ways, and generate different
	answers depending on its interpretation.  When side effect (assignment
	to actual variables) takes place is left to the discretion of the
	compiler, since the best order strongly depends on machine architeture.

	The moral of this discussion is that writing code which depends on
	order of evaluation is a bad programming practice in any language.
	Naturally, it is necessary to know what things to avoid, but if you
	don't know how they are done on various machines, that innocence may
	help to protect you.  (The C verifier lint will detect most dependencies
	on order of evaluation.)