From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,fee8802cc3d8334d
X-Google-Attributes: gid103376,public
X-Google-Thread: 10a146,fee8802cc3d8334d
X-Google-Attributes: gid10a146,public
From: D'Arcy Smith <nospam@itools.symantec.com>
Subject: Re: Ada and Java. different behaviour. casting long to int problem.
Date: 1999/06/16
Message-ID: <3767DB65.553608AC@itools.symantec.com>#1/1
X-Deja-AN: 490334947
Content-Transfer-Encoding: 7bit
References: <7jt2c0$vrb@drn.newsguy.com> <f92d7yyweva.fsf@eng.sun.com>
 <7k57vb$1ipf@drn.newsguy.com> <3766650F.705125B7@pwfl.com>
 <7k64t7$igo$1@its.hooked.net> <7k689a$ci2@drn.newsguy.com>
 <3766C842.E1EAB60A@pwfl.com> <3766D1CC.D712895E@itools.symantec.com>
 <3767CDFC.798BBB23@cajunbro.com>
To: "George W. Bayles" <georgeb@cajunbro.com>
X-Accept-Language: en
Content-Type: text/plain; charset=us-ascii
X-Complaints-To: news@itools.symantec.com
X-Trace: it.visualcafe.com 929553112 18918 155.64.77.40 (16 Jun 1999 17:11:52
 GMT)
Organization: Internet Tools Division, Symantec Corp.
Mime-Version: 1.0
NNTP-Posting-Date: 16 Jun 1999 17:11:52 GMT
Newsgroups: comp.lang.ada,comp.lang.java.programmer
Date: 1999-06-16T17:11:52+00:00
List-Id: <comp.lang.ada>

"George W. Bayles" wrote:

> > Could the language be defined differently to point out overflow
> > erorrs?  Sure.

> Perhaps you assume that all processors can automatically detect
> integer overflow in hardware? Any requirement wrt handling integer
> overflow you make in the language would incur severe performance
> penalties if the hardware doesn't support it.

No I don't assume it - I was thinking that it could be an optional
operation that the compiler could do... but thinking more about it
that belongs at the VM level.

If it is optional (like "strictfp") then people at least know that
there will be a performance penalty that changes depending on the VM 
implementation.


> It's a tradeoff - safety vs performance. How much safety are you
> losing though? Almost all the integer ops in a real program will
> never overflow. The few that can overflow can be readily checked

> int a,b,c;
> ....
> a = b + c;
> boolean overflowed = (c<0) ? (a>b) : (a<b);

And you could provide a class do that (it wouldn't be as nice
and nobody start on overloaded operators!):

   // just using what you did above
   public class SafeMath
   {
       public int add(int a, int b) 
       {
           int result;

           result = b + c;
           
           if(b < 0) ? (result > a) : (result < a)
           {
               // a runtime exception.
               throw new UverflowException(a + " + " + b);   
           }
       }

       etc...
   }

   ...
   try
   {
       SafeMath.add(5, 6);
   }
   catch(OverflowException ex)
   {
   }
   ...

The try/catch are optional.

This solution is nice because it requres no language change and is
easy to implement.  The downside is that there is a performance hit 
regardless of your hardware... it also doesn't look real pretty :-)

..darcy
-- 
D'Arcy Smith
Sr. Software Engineer
Symantec, Internet Tools Division

If you simply reply to this email it will get forwarded to /dev/null
My Email address is darcy at itools dot symantec dot com