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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.58.38.199 with SMTP id i7mr1429049vek.6.1400106319199; Wed, 14 May 2014 15:25:19 -0700 (PDT) X-Received: by 10.50.6.103 with SMTP id z7mr646046igz.11.1400106319101; Wed, 14 May 2014 15:25:19 -0700 (PDT) Path: border1.nntp.dca.giganews.com!nntp.giganews.com!r10no4707944igi.0!news-out.google.com!qf4ni926igc.0!nntp.google.com!c1no6834030igq.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Wed, 14 May 2014 15:25:18 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=66.126.103.122; posting-account=KSa2aQoAAACOxnC0usBJYX8NE3x3a1Xq NNTP-Posting-Host: 66.126.103.122 References: <50562e0a-3dfa-44c4-9aaa-70cbe304b54b@googlegroups.com> <40c7405d-c4c2-4163-a430-01052b769866@googlegroups.com> <049c868a-e930-4e5d-a96a-611542cd1ce6@googlegroups.com> <224148c3-2a31-4f3e-a3a3-0a588773798b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <34002dc0-6332-4b5d-9f47-c3946a96a6f1@googlegroups.com> Subject: Re: Bug or feature? From: Adam Beneschan Injection-Date: Wed, 14 May 2014 22:25:19 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: number.nntp.dca.giganews.com comp.lang.ada:186418 Date: 2014-05-14T15:25:18-07:00 List-Id: On Wednesday, May 14, 2014 3:02:16 PM UTC-7, Robert A Duff wrote: =20 > >... It looks like there's a bug in how range checking is > > handled if -gnato isn't used, over and above the lack of overflow > > checking. >=20 > No, I don't think so. If you don't use -gnato, it's equivalent > to having pragma Suppress(Overflow_Check), so if it overflows, > all bets are off. I see your point, so I guess "bug" may have been the wrong term. "Interest= ing inconsistency" may be better. It's interesting that, when overflow che= cking is suppressed, the compiler seems to figure out that it can assume "+= " of two Positive values is Positive and doesn't need to be checked, but do= esn't figure this out for "*". OK, without trying to look at the compiler's source code, this seems like a= reasonable explanation: subtype S1 is Integer range Low1 .. High1; subtype S2 is Integer range Low2 .. High2; X1 : S1; X2 : S2; X1+X2 is always in the range Low1+Low2 .. High1+High2, but there's no such = simple way to express the range of X1*X2 (in general). Could that be the r= eason for the difference in behavior? =20 -- Adam