DEFINITE bug in Turbo C 2.0

[William B. Tyler]

In article <802 at zeusa.UUCP> hendrik at zeusa.UUCP (Hendrik Vermooten) writes:
]Here is a definite bug in C (discovered by Renier v. Wyk)
]
]#include <stdio.h>
]#define SQR(a) a*a
]main ()
]{
]	int a = 10, b = 10, x, y;
]
]	x = SQR (++a);
]	y = SQR (b++);
]	printf ("%d\n", x);
]	printf ("%d\n", y);
]	a = 10;
]	b = 10;
]	printf ("%d\n", SQR (++a));
]	printf ("%d\n", SQR (b++));
]}
]
]Run by Turbo C it gives:
]
]144
]100
]132
]110
]
]And run by Microsoft C (under XENIX):
]
]132
]110
]132
]110

My reading of the ANSI standard implies that the order of 
storing the incremented results as compared to the order of
the other operations is not necessarily well-defined.  In
other words, this may not be an error.  Note that an implementation
is not required to evaluate similar expressions in the same
order in all circumstances.

I'd like to see some well-informed comment on this point.
-- 
Bill Tyler				...(tolerant|hpda)!procase!tyler