Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!ucsd!ucbvax!SNOWHITE.CIS.UOGUELPH.CA!mike
From: mike@SNOWHITE.CIS.UOGUELPH.CA
Newsgroups: comp.sys.sgi
Subject: Fun and games with ++ operators
Message-ID: <9009211425.AA04291@snowhite.cis.uoguelph.ca>
Date: 21 Sep 90 14:25:43 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 38

Greetings and obeisances, O SGI sages!

    I have found a peculiarity in the MIPS C compiler that is more of a 
curiosity than a problem, but I wonder if someone could shed some light on
it anyway, just for fun.

    Here is a sample program that exhibits the peculiar behavior:
		#include <stdio.h>
		int a [2];
		main()
		{
			int i;
			a[0] = 5;
			a[1] = 6;
			i = 0;
			printf("%d %d\n", a[i++], a[i++]);
		}
    Depending on the order of evaluation of function arguments, I would expect
this code to generate "6 5" or "5 6".  But instead it says "5 5", which 
confuses me a bit.  Do all pre/post increment/decrement operators only
take effect after the current source line, or what?  I did check the value
of 'i' on the next line, and it was indeed 2, so that part works.  For C
reference I only have the ancient K&R, which as far as I can tell does not
formally specify when these operators are supposed to do their thing.  For
reference purposes, I ran this code on many platforms (6 different CPUs, 
8 different compilers), and only the MIPS compiler came out with the "5 5"
answer.

    This phenomenon is no skin of my shins, as I have always felt that overuse
of these operators is bad form anyways.  But it would be nice to know just 
what the official line is on this case, and how far we can expect optimizing
compilers to stretch our assumptions about language semantics.

    Thanks for not laughing too much.

World's shortest SF story:           |  Mike Chapman
"Aliens disguised as workstations?   |  Grab Student, University of Guelph
 I never heard such--"               |  mike@snowhite.cis.uoguelph.ca