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 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,4eca860272d4832b
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news2.google.com!postnews.google.com!a34g2000cwb.googlegroups.com!not-for-mail
From: "Adam Beneschan" <adam@irvine.com>
Newsgroups: comp.lang.ada
Subject: Re: Static vs dynamic evaluation anomaly?
Date: 7 Feb 2007 17:26:11 -0800
Organization: http://groups.google.com
Message-ID: <1170897971.419567.78410@a34g2000cwb.googlegroups.com>
References: <12shen4qjhv41a7@corp.supernews.com>
   <1170792077.235994.10900@q2g2000cwa.googlegroups.com>
   <HI6dnX9pKMXb1VTYnZ2dnUVZ_vupnZ2d@comcast.com>
   <87d54mguco.fsf@ludovic-brenta.org>
   <1170843700.7656.47.camel@localhost.localdomain>
   <1170866664.465875.309930@v45g2000cwv.googlegroups.com>
   <GSoyh.1178127$084.353645@attbi_s22>
   <1170874545.463017.180430@j27g2000cwj.googlegroups.com>
   <truyh.261466$aJ.73533@attbi_s21>
NNTP-Posting-Host: 66.126.103.122
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-Trace: posting.google.com 1170897986 4658 127.0.0.1 (8 Feb 2007 01:26:26
 GMT)
X-Complaints-To: groups-abuse@google.com
NNTP-Posting-Date: Thu, 8 Feb 2007 01:26:26 +0000 (UTC)
In-Reply-To: <truyh.261466$aJ.73533@attbi_s21>
User-Agent: G2/1.0
X-HTTP-UserAgent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
 rv:1.7.12) Gecko/20050922 Fedora/1.7.12-1.3.1,gzip(gfe),gzip(gfe)
Complaints-To: groups-abuse@google.com
Injection-Info: a34g2000cwb.googlegroups.com; posting-host=66.126.103.122;
   posting-account=cw1zeQwAAABOY2vF_g6V_9cdsyY_wV9w
Xref: g2news2.google.com comp.lang.ada:9120
Date: 2007-02-07T17:26:11-08:00
List-Id: <comp.lang.ada>

On Feb 7, 4:48 pm, "Jeffrey R. Carter" <jrcar...@acm.org> wrote:

> What's happening (I think) is the base type is 8 bits. Without -gnato,
> there's no check to see if the result exceeds this and should be reduced
> mod the modulus, so an out-of-range value is produced.

Hmmm.  This is certainly not the way I would expect a "perform this
check" or "don't perform this check" flag to work.  To me, if the
semantics of the language say that a value should be reduced by a
modulus, then it should always be reduced regardless of what flags are
present.  The only effect I'd expect a flag like this to have is in a
case where performing a check would raise an exception; then not
performing the check would have different behavior (possibly returning
an out-of-range value or reading out-of-range memory or dying on an
invalid memory access or something).  But I wouldn't expect any change
in behavior in a case where no exception is raised even with checking
turned on.

                              -- Adam