Xref: utzoo comp.lang.c:27169 comp.std.c:2671
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!ucbvax!hplabs!nsc!voder!procase!tyler
From: tyler@procase.UUCP (William B. Tyler)
Newsgroups: comp.lang.c,comp.std.c
Subject: Re: DEFINITE bug in Turbo C 2.0
Summary: Not so definitely a bug
Message-ID: <103@sail.procase.UUCP>
Date: 23 Mar 90 20:35:15 GMT
References: <802@zeusa.UUCP>
Reply-To: tyler@procase.UUCP (William B. Tyler)
Followup-To: comp.lang.c
Organization: proCASE Corporation, Santa Clara, CA
Lines: 43

In article <802@zeusa.UUCP> hendrik@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