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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: Java vs Ada 95 (Was Re: Once again, Ada absent from DoD SBIR solicitation) Date: 1996/10/17 Message-ID: #1/1 X-Deja-AN: 190240134 references: <325D7F9B.2A8B@gte.net> organization: New York University newsgroups: comp.lang.ada Date: 1996-10-17T00:00:00+00:00 List-Id: "No, Java defines the result as wrap-around arithmetic. So an overflow will give you the "wrong" answer (at least *I* would call it wrong, in most situations), but it always gives you the *same* wrong answer on all machines." Oh, sorry, I did not realize this (it never occurred to me that a language definition would mandate such patently unpleasant semantics for integer arithmetic, sounds like an implementor rather than a language designer at work if you ask me). OK, we can't duplicate that arithmetic in Ada directly, and that is not surprising, a semantics whhere you can add two positive numbers and get a negative number is not exactly attractive to provide as a primitive. If you really really want such strange arithmetic (perhaps to acomodate a Java-to-Ada translator :-) then you could program it easily enough using unchecked conversion and modular and signed arithmetic mixed in the appropriate odd way.