Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!nrl-cmf!ames!ncar!tank!uxc!uxc.cso.uiuc.edu!zaphod!liberte
From: liberte@zaphod.ncsa.uiuc.edu
Newsgroups: comp.sys.mac.programmer
Subject: Re: Overflow Checking from within Pasca
Message-ID: <900006@zaphod>
Date: 3 Oct 88 23:08:00 GMT
References: <4276@polyslo.CalPoly.EDU>
Lines: 31
Nf-ID: #R:polyslo.CalPoly.EDU:4276:zaphod:900006:000:1519
Nf-From: zaphod.ncsa.uiuc.edu!liberte    Oct  3 18:08:00 1988


This is not an answer to your question about doing overflow checking
on longints.  However, the following suggestion may help someone who is
trying to do unsigned integer arithmetic in LSP.  

My need was to do arithmetic on the unsigned integer components of
colors.  There is no way to declare unsigned integers, and in a recent
conversation with Symantec support people I learned that there is no
plan to support unsigned integers in the next version of Pascal.  

An integer value that has the high bit set is
considered negative.  One bit pattern in particular is an illegal value
which you cannot do arithematic on: 32768=$8000.  However, you can cast
it to a longint, but then the sign is extended.  The simple solution is
to zero out the upper word of the longint using BitAnd with $0000FFFF
as an argument.   Then do your arithmetic and finally select the low
word of the result with LoWord.

This all works.  But there is one final problem.  You cannot assign the
value 32768 back into an integer variable.  I have no solution to this
problem other than turning overflow checking off.  But unfortunately, I
discovered that I cannot turn off this overflow checking, even if I
turn it off for the whole project.  Is this a bug?

In my case, I can check for this illegal value while it is still
longint and subtract one before taking the LoWord.  But this is
an ugly hack, and LSP is broken when it comes to unsigned integers.

Dan LaLiberte
National Center for Supercomputing Applications
liberte@ncsa.uiuc.edu