🚀 go-pugleaf

I've run the a = ((b=1),b) + ((b=2),b) + ((b=3),b) ; program on several
compilers (AT&T 370 C compiler, Masscomp C compiler, IBM ACIS 4.2
compiler for the IBM RT/PC, and the PC/IX compiler) and they all get 9.
I'm also essentially positive that all these compilers are PCC based.
I recently had a chance to read the minutes from the June 1986 ANSI C
standardization meeting.  It seems to me that they have made it
mandatory for the result to be 6 (the relevant point is that the comma
operator provides a "sequence point").  The only draft of the full ANSI
standard that I have is well over a year old and it seems to me to leave
the order of evaluation as "implementation dependent".  The change from
the April 1985 draft to the current version (under the assumption that
I've got it straight) would seem to make many current compilers (most
PCC based compilers) out of compliance with the standard.  This isn't
necessarily a bad thing per se (code that depends on this behavior of
PCC derived compilers is clearly non portable), but I'm not sure that
having the order of evaluation specified for comma operators is worth
the trouble it might cause optimizing compilers.  Besides, if (as it
seems) PCC derived compilers do "for effect" evaluations first, there
might be more reasonable code that is "broken" by this change.

Of course, I speak only for myself, not my employer.

			Josh Knight
			IBM T.J. Watson Research Center
josh@ibm.com, josh@yktvmh.BITNET