Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site cincy.UUCP
Path: utzoo!linus!philabs!cmcl2!floyd!harpo!eagle!mhuxl!ihnp4!cbosgd!qusavx!cincy!jreuter
From: jreuter@cincy.UUCP (Jim Reuter)
Newsgroups: net.lang.c
Subject: ++ operator
Message-ID: <1166@cincy.UUCP>
Date: Tue, 27-Dec-83 18:30:50 EST
Article-I.D.: cincy.1166
Posted: Tue Dec 27 18:30:50 1983
Date-Received: Fri, 30-Dec-83 00:24:25 EST
References: <122@taurus.UUCP>, <1092@mit-eddie.UUCP>
Organization: U. of Cincinnati ECE
Lines: 31

dave@taurus notes:
	Uh-uh:
		if(*in++ == *in++)

	...

	Also, for those of little faith, there are actually C compilers that
	will take the non-obvious meaning of this (e.g. the PDP-11 cc), and do
	the tests then do both increments in one go after the statement,
	so BE WARNED.
mp@mit-eddie replies:
	I just tried this with the V7 cc, 4.1bsd pcc, and VAX-11 C compilers,
	and in each case two increments were done.

(The implied meaning is that they were done in the proper place.  They
are, I just tested it.)

The real problem here is the ORDER of the increments.  In this example,
order would not matter.  A nice simple example of ordering problems shows
up in the v7 Ritchie compiler:

	int i = 0;

	printf(" %d %d %d %d\n", i++, i++, i++, i++ );

which produces

	3 2 1 0

	Jim Reuter
	(decvax!cincy!jreuter)