DEFINITE bug in Turbo C 2.0

[Steve Summit]

In article <451 at wattres.UUCP> steve at wattres.UUCP (Steve Watt) writes:
>Some more votes:
...
>Interesting...
>...but I can sure understand most of the others, except for cc under Ultrix...

In article <1990Mar23.074526.8286 at ncsuvx.ncsu.edu> dks at shumv1.ncsu.edu (D. K. Smith) writes:
>...I decided 
>to compare the results of the above code on my THINK C 3.02 compiler...

It has already been explained that the referenced code yields
undefined, compiler-dependent behavior.  Investigate it further
if you must, but please don't post the results here.  Which
"answer" a particular compiler gives is simply not useful (nor
particularly interesting).

In article <1990Mar23.073923.6425 at cs.eur.nl> reino at cs.eur.nl (Reino de Boer) writes:
>I think the point made was not that the results should be the same, but
>that... both computations [should] leave (11 * 12) in "x".

Don't make the common mistake of believing that x++ increments x
just after yielding its former value, but before doing anything
else in the expression.  The incrementation merely happens later,
sometime before the following _statement_ is executed (formally,
before the next "sequence point"), but it need not happen before
the next use of x in the same expression.  (The "relative
precedence of '++' and '*'" doesn't really enter into it.)

                                            Steve Summit
                                            scs at adam.pika.mit.edu