Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!seismo!mcvax!ukc!eagle!icdoc!cam-cl!am
From: am@cam-cl.UUCP
Newsgroups: comp.lang.c
Subject: Re: MSC C arithmetic
Message-ID: <1046@jenny.cl.cam.ac.uk>
Date: Mon, 17-Aug-87 11:18:49 EDT
Article-I.D.: jenny.1046
Posted: Mon Aug 17 11:18:49 1987
Date-Received: Sat, 22-Aug-87 09:05:25 EDT
References: <8792@brl-adm.ARPA> <7976@mimsy.UUCP>
Reply-To: am@cl.cam.ac.uk (Alan Mycroft)
Organization: U of Cambridge Comp Lab, UK
Lines: 22

In article <7976@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
[discussing:]
>>	double total_bits;
>>	unsigned int repeat_cnt, units, blksiz;
>>	total_bits = repeat_cnt * units * blksiz * 16.0
>[produce unexpected results].
>
>The second result is not so defensible; the 16.0 should modify the
>entire operation so that it is done in double.
> [...] type_double; this propagates all the way back to the top.
>
I believe this to be a mis-reading of the rules.
The expresion 'repeat_cnt * units * blksiz * 16.0' parses as
'((repeat_cnt * units) * blksiz) * 16.0' as * is defined
to be left associative.  The fact that '((repeat_cnt * units) * blksiz)'
is evaluated in 'double' context is not relevant.
The fix is to write
  '(double)repeat_cnt * units * blksiz * 16.0' or
  'repeat_cnt * (units * (blksiz * 16.0))'.
to force more multiplications to be done in double mode.
  '(unsigned long)repeat_cnt * units * blksiz * 16.0' probably gives
exact correspondence with 32-bit int machines.