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: 10a146,fee8802cc3d8334d X-Google-Attributes: gid10a146,public X-Google-Thread: 103376,fee8802cc3d8334d X-Google-Attributes: gid103376,public From: Mark Hood Subject: Re: Ada and Java. different behaviour. casting long to int problem. Date: 1999/06/14 Message-ID: #1/1 X-Deja-AN: 489629100 References: <7jt2c0$vrb@drn.newsguy.com> <7jv4bh$11rg@drn.newsguy.com> <7jvcqv$od9$1@nnrp1.deja.com> <7jvj7r$1nj8@drn.newsguy.com> Organization: Sun Microsystems Inc., Mountain View, CA Newsgroups: comp.lang.ada,comp.lang.java.programmer Date: 1999-06-14T00:00:00+00:00 List-Id: Fred@moon.com.spam_free writes: > OK, so you are in the middle of lengthy calculation, with some > intermediate results being generated on the fly, and an > overflow occurs. > > In Java, nothing happens, and life goes on and the final number is wrong, > but no one really knows it is wrong, or may be someone will notice it is > wrong. I think the point is that the result of an overflow isn't necessarily the wrong number. For example, one could be working with data that needs to be expressed in some signed 16-bit quantized space, and wish to encode consecutive elements in that space as deltas from previous values in a streamed fashion. In that case the overflow semantics are essential, since otherwise it wouldn't be possible to express the delta between -30000 and +30000 in 16 bits. The example isn't contrived; it's common in compression algorithms. My impression is that Ada is oriented toward numerical applications, and so the overflow checks are probably appropriate. It would certainly be inconvenient for many Java applications if the defined behavior of signed 2's complement integers were thwarted. -- Mark Hood