Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: Notesfiles $Revision: 1.7.0.10 $; site uiucdcsb
Path: utzoo!linus!decvax!bellcore!ulysses!mhuxr!mhuxt!houxm!ihnp4!inuxc!pur-ee!uiucdcs!uiucdcsb!wsmith
From: wsmith@uiucdcsb.CS.UIUC.EDU
Newsgroups: net.lang.c
Subject: Re: *p++ = *p and more
Message-ID: <139200024@uiucdcsb>
Date: Wed, 2-Apr-86 14:54:00 EST
Article-I.D.: uiucdcsb.139200024
Posted: Wed Apr  2 14:54:00 1986
Date-Received: Sat, 5-Apr-86 05:45:28 EST
References: <16634@rochester.ARPA>
Lines: 20
Nf-ID: #R:rochester.ARPA:16634:uiucdcsb:139200024:000:892
Nf-From: uiucdcsb.CS.UIUC.EDU!wsmith    Apr  2 13:54:00 1986


I think compilers can do the post-increment anytime they feel like it
with in the statement.     The semantics of a[i] = b[i++];   isn't
defined so the compiler can do whatever it wants.  Even if that means
that both i's are evaluated before the increment is done.

f(i++,i++,i++,i++);    is a similar statement.   Most compilers do a 
reasonable thing although you don't know a priori if it is evaluated
left to right or right to left.  The Tartan C compiler optimizes it so
that there aren't even 4 increments done.   Only one increment per statement
per variable is unambiguous so that is all the compiler seems to do.

The moral of this story:   I something is undefined in a language, don't do it.
	You're adding compiler dependencies and are generally asking for 
	trouble.
(lint would complain about such a construct: "order of evaluation undefined")


Bill Smith
ihnp4!uiucdcs!wsmith