Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!rpi!uupsi!sunic!dkuug!imada!ravn
From: ravn@imada.ou.dk (Thorbjoern Ravn Andersen)
Newsgroups: comp.lang.pascal
Subject: Re: Is this a bug in TurboPascal? (answer: no)
Message-ID: <1991May6.120929.29411@imada.ou.dk>
Date: 6 May 91 12:09:29 GMT
References: <1991May1.021059.2129@ux1.cso.uiuc.edu> <1991May1.191049.557@csc.canterbury.ac.nz>
Sender: news@imada.ou.dk (USENET News System)
Organization: Dept. of Math. & Computer Science, Odense University, Denmark
Lines: 33

phys169@csc.canterbury.ac.nz writes:

[Stuff deleted]
>longint (or reals, if you like), or change the code to..
>  c1 := Trunc(50.0*xx/639.0); c2 := Trunc(50.0*yy/479.0);
>  c3 := Trunc(300.0*yy/639);  c4 := Trunc(250.0*yy/479.0);

>The reason this works is that 300.0*yy is a real result, which goes on to the
>division by 639 (or 639.0, either will do, but 639.0 is preferrable).

You may also force the computation into real mode, by doing the
division first.  Calculating it like
   
   c3:= Trunc(300/639 * yy)

will have the same result.  I do like this because I do not think the
.0's are pretty.  I do not know, however, how this may affect your
portabillity with other compilers.  [BTW. This was checked with Turbo
5.0, I do not know if it has been changed in later versions]
  

>BTW, it is a good idea to make sure range checking is on; it catches some
>cases like this (but not this particular one, I'm afraid). 

As far as I know, there is *NO* checking on overflow on integer
calculations.  The range check is only active in subranges and index
variables.

-- 
Thorbj\o{}rn Ravn Andersen 'Normally I kill people for money.  You are my
ravn@imada.ou.dk            friend; I will kill you for nothing' -- Chico Marx

Justice, n.: