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=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!sdd.hp.com!ucsd!ucbvax!IBM.COM!NCOHEN From: NCOHEN@IBM.COM ("Norman H. Cohen") Newsgroups: comp.lang.ada Subject: Fixed times Integer Message-ID: <9008301533.AA11448@ajpo.sei.cmu.edu> Date: 30 Aug 90 15:10:20 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet List-Id: Marc Graham questions the message indicating that NUMERIC_ERROR will be raised at the point of the numeric literal 32768 in the following program: procedure junk is type blarb is delta 0.1 range 0.0 .. 32769.0; thing : blarb; begin if thing * 32767 > thing * 32768 then null; end if; end junk; Technically, the exception is raised not by the multiplication, but by the implicit conversion of the universal integer value 32,768 to type Integer (which is 16 bits in Marc's implementation). This is explicitly justified by RM 3.5.4(10). However, an implementation is allowed to be more reasonable. That same paragraph goes on to say, "However, an implementation is not required to raise the exception NUMERIC_ERROR if the operation is part of a larger expression whose result can be computed correctly, as described in section 11.6." (The full rule is given in RM 11.6(5), which I will not quote here because all readings of that paragraph generate more questions than they answer.) In the example above, there are values of THING for which the enclosing expression can be successfully evaluated, so the compiler is not being as helpful as it could be. I wonder how it treats I: Integer := -32768; (in which evaluation of the initial value technically consists of conversion of the universal_integer value 32768 to type Integer followed by invocation of the negation operator for type Integer).