Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!cbatt!gatech!lll-lcc!seismo!mimsy!chris
From: chris@mimsy.UUCP
Newsgroups: comp.unix.questions
Subject: Re: Evaluating autoincrements in function calls
Message-ID: <5604@mimsy.UUCP>
Date: Thu, 26-Feb-87 16:40:51 EST
Article-I.D.: mimsy.5604
Posted: Thu Feb 26 16:40:51 1987
Date-Received: Sat, 28-Feb-87 06:37:51 EST
References: <4707@brl-adm.ARPA> <3279@rsch.WISC.EDU>
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37

>In article <4707@brl-adm.ARPA> welch%UMASS.BITNET@wiscvm.wisc.EDU writes:
>>int    set[]={1,2,3}, i = 0;
>main() {
>printf("\nnumbers in set indexed by incr integer = %d,%d,%d",
>    set[i++], set[i++], set[i++]);
 
[produces different results with different compilers].

In article <3279@rsch.WISC.EDU> mcvoy@rsch.WISC.EDU (Lawrence W. McVoy) writes:
>This is explicitly undefined in the K&R definition,

And in the ANSI draft standard.

And then in an aside:

>It is unfortunate, though.  Inconsistencies suck.

What inconsistencies?  Those between different compilers?  One must
expect some.  What does the following program, written in ZIFP (zifp
is for pedantry :-) ) do when translated to your favourite Pascal-like
language?

	proc sighed returns program_status <- {
	    var i: integer <- 0;
	    // `set' is a reserved word in this imaginary language
	    var iset: array [integer: 0..2] of integer <- {1, 2, 3};
	    proc f returns integer <- {
		f <- iset[i];
		i <- i + 1;
	    }
	    print("numbers in set: ", f, f, f);
	    sighed <- success;
	}

-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
UUCP:	seismo!mimsy!chris	ARPA/CSNet:	chris@mimsy.umd.edu