++ operator

Donn Seeley donn at sdchema.UUCP
Wed Jan 4 16:28:27 AEST 1984

Not that this constitutes a holy war, but I strongly agree with Dave
Lukes that the order of evaluation of side effects is (and should be)
undefined.  Even if side effects had a dependable order of evaluation,
programs that depended on this order would be very difficult for the
programmer in the street to interpret.  I'm not (necessarily) an
advocate of functional programming but I don't think that this attitude
is unreasonable.  Also, by restricting the order of evaluation of these
side effects you might disallow some (otherwise) reasonable

I really wanted to contribute an example of a compiler difference in
order of evaluation of side effects.  This incident actually happened
-- you can try it for yourself if you don't believe it.  Some poor
researcher's C program to convert plot data ran on V6 on an 11/40 but
broke under 4.1 on the VAX.  (We ran phototypesetter V7 C on the
11/40, if it makes any difference.)

When I looked at his program I discovered code like the following:

	int data[8];
	int *R;
	int count;
	R = data;
	count = *R++ + *R++ + *R++ + *R++ + *R++ + *R++ + *R++ + *R++;

Some unthinking systems programmer had casually informed the poor
researcher that pointer references were faster than subscript
indirection.  From there it was a short step to concluding that side
effects are done from left to right (obvious, huh? -- well, at least
you TYPE the side effects in from left to right).  When he compiled and
ran the program on V6, it worked just as he expected.  Unfortunately
the VAX compiler (with -O) does all of the increments AFTER doing all
of the additions...  (And clumsily, too: it does all the increments
separately instead of conflating them into a single add.)

So, yes, commonly used C compilers DO differ in order of evaluation of
postincrement and other side effects.

Donn Seeley    UCSD Chemistry Dept. RRCF    ucbvax!sdcsvax!sdchema!donn

More information about the Comp.lang.c mailing list