Hi Alan,
You wrote to me:
AC> GW>>> According to the rules the two longs should be promoted to float
AC> GW>>> before the calculation, the calculation made and then the result
AC> GW>>> cast back to long (which discards any fractional part).
AC> AC>> Aren't the two longs multiplied first before the result is
AC> AC>> promoted?  Promoted to what?  The two manuals I've got
AC> AC>> disagree.  Mix Power C says floats are promoted to double.
AC> AC>> Turbo C manual says that float stays float.
AC> GW> As I read it all promotions occur before the calculation is made.
AC> GW> bicbw (and if I am I'm sure to be corrected).
AC>Using Turbo, I get the following results for the code
AC>below.  If everything was promoted, resultf would be the
AC>same as resultfi.  An interesting result from 30000 * 30000
AC>though.
That's overflow in the integer calculation...
AC>resulti -17664
AC>resultf -17664.000000
AC>resultfi 2700000000.000000
I changed it to:
AC>#include 
AC>int main(void) {
AC>int a = 30000, b = 30000, multii = 3, resulti;
AC>float multif = 3.0, resultf, resultfi;
float resultf1;
AC>resulti = a * b * multii;
AC>resultf = a * b * multif;
resultf1 = multif * a * b;
AC>resultfi = (float)a * b * multif;
AC>printf("resulti %d\n", resulti);
AC>printf("resultf %f\n", resultf);
printf ("resultf1 %f\n,resultf1);
AC>printf("resultfi %f\n", resultfi);
AC>return 0;
AC>}
and with BC 3.1 got :
resulti -17664
resultf -17664.000000
resultf1 2700000000.000000
resultfi 2700000000.000000
Which is bad news, as obviously the Borland parser only does the
conversion to float when it encounters one in the source stream. afaiaa
this is not strictly ANSI compliant, as rearranging the order should not
change the result. Hopefully one of the experts with a copy of the
standard will check this for us.
I've checked BCOS/2 V1.0 and it gets 2700000000.000000 for resultf
(probably, it certainly gets that value, but crashed on the output :-(
).
IBM Visualage C++ V3 also gets the correct value.
These results don't change if the int declaration is changed to short.
So, as far as I'm concerned, the Borland compiler you've got & my BC 3.1
both have faulty parsers in this case and my understanding of the rules
still looks correct
George
 * SLMR 2.1a * All Trademarks acknowledged (just in case ).
--- Maximus/2 3.01
---------------