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!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!IBM.COM!NCOHEN
From: NCOHEN@IBM.COM (Norman Cohen)
Newsgroups: comp.lang.ada
Subject: (none)
Message-ID: <030989.170746.ncohen@ibm.com>
Date: 9 Mar 89 22:07:46 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
List-Id: <comp.lang.ada>

Subject: More on implicit conversion

Ref: INFO-ADA Digest Volume 89 Issue 72 (Wed, Mar 8, 1989) Item #4
     (by Steven Holtsberg)
     INFO-ADA Digest Volume 89 Issue 75 (Thu, Mar 9, 1989) Item #5
     (by Vladimir Ivanovic)
     INFO-ADA Digest Volume 89 Issue 75 (Thu, Mar 9, 1989) Item #8
     (by me)

It has been pointed out to me that I missed Steven Holtsberg's point:
MAX_INT is not in the range of type Tiny_Integer, so if MAX_INT were
converted to Tiny_Integer as required by the rules in RM 4.6(15), one
would expect Numeric_Error or Constraint_Error to be raised.

RM paragraph 11.6(6) provides a loophole for the exception not to be
raised.  Formally, the compiler is performing the two Tiny_Integer
conversions and the Tiny_Integer subtraction using a type with a wider
range than Tiny_Integer.  In reality, of course, the compiler is probably
computing the zero difference at compile time, but that's none of our
business.  See the note in RM 11.6(9) for another example of this
loophole.

Apparently the Verdix compiler used by Steven Holtsberg exploits this
loophole while the DEC v1.5 compiler used by Vladimir Ivanovic does not.
Neither compiler is wrong.

Norman Cohen