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,3ccb707f4c91a5f2 X-Google-Attributes: gid103376,public From: bobduff@world.std.com (Robert A Duff) Subject: Re: Portability of Arithmetic (was: Java vs Ada 95) Date: 1996/10/18 Message-ID: #1/1 X-Deja-AN: 190321561 references: <325D7F9B.2A8B@gte.net> <1996Oct18.074034.1@eisner> organization: The World Public Access UNIX, Brookline, MA newsgroups: comp.lang.ada Date: 1996-10-18T00:00:00+00:00 List-Id: In article <1996Oct18.074034.1@eisner>, Larry Kilgallen wrote: >I thought the claim was made that those "bad" (I hope that is not a >reserved word) Java results would be the same from machine to machine. >That at least raises the hope that bugs which did not bite you on >machine A will also not bite you on machine B. If that hope is >fulfilled, then it would seem that Java arithmetic is portable. > >I am not saying Java arithmetic is "good", since the first person to >provide subtly different input on any platform might get undesired >behaviour. But to the extent that the undesired behaviour is uniform >across all platforms, Java arithmetic is "portable". That's exactly what I've been trying to say. Thanks for saying it more clearly than I have. I'm the the one that claimed that Java arithmetic is portable even in the presence of overflow. Several people have questioned that, so I looked it up in "The Java Language Specification". In section 15.17.2, page 358, it says, "If an integer addition overflows, then the result is the low-order bits of the mathematical sum as represented in some sufficiently large two's complement format." Subtraction is defined so a-b is the same as a+(-b). Unary minus is defined in 15.14.4 so -x equals (~x)+1, where ~ is the bit-wise complement operator. 15.16.1 talks about multiplication, and says something similar about overflows. I didn't bother to look up all the operators. So, an overflow in Java always produces the same answer. It is *not* equivalent to pragma Suppress(Overflow_Check) in Ada. So in general, the ranges supported are portable, and the behavior of the operators is portable. Neither of these is true for Ada. In Ada, you *can* write portable arithmetic in practise, if you stick to 32-bits or less, and are careful about overflows in intermediate results. You can also accidentally write non-portable arithmetic. In Java, you can't make that mistake. Whether this is an advantage of Java is open to debate, of course -- the portability comes at some substantial run-time cost on machines with strange word sizes. In fact, Java is more portable than Ada in a *lot* of ways. I'm about 2/3 of the way through the Java book, and the only non-portabilities I've noticed are (1) getting Out_Of_Memory_Error and (2) the behavior of multiple threads reading and writing shared variables. - Bob