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-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,5095dad989e89e23
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2000-12-13 12:46:12 PST
Path: 
 supernews.google.com!sn-xit-02!supernews.com!newsfeed.mesh.ad.jp!news.tele.dk!193.174.75.178!news-fra1.dfn.de!fu-berlin.de!news.cid.net!news.enyo.de!news2.enyo.de!news1.enyo.de!not-for-mail
From: Florian Weimer <fw@deneb.enyo.de>
Newsgroups: comp.lang.ada
Subject: Re: Does a null pointer always raise Constraint_Error?
Date: 13 Dec 2000 21:07:01 +0100
Organization: Enyo's not your organization
Message-ID: <87zoi0w0ey.fsf@deneb.enyo.de>
References: <Pine.LNX.4.10.10011301306120.793-100000@lexis.di.fct.unl.pt>
 <tgzoihpon4.fsf@mercury.rus.uni-stuttgart.de> <9074fi$93b$1@nnrp1.deja.com>
 <3A3253B1.AD8F32CF@ebox.tninet.se> <90u1vi$uah$1@nnrp1.deja.com>
 <90ukfm$c4p$1@nnrp1.deja.com> <3A36511D.973D82BD@nowhere.com>
 <yec1yvdtmf1.fsf@king.cts.com> <916gsr$e6e$1@nnrp1.deja.com>
 <slrn93eect.i1.lutz@taranis.iks-jena.de>
 <IeLZ5.7495$bw.651358@news.flash.net>
 <slrn93f1ic.vo.lutz@taranis.iks-jena.de>
 <tgn1e0mkqh.fsf@mercury.rus.uni-stuttgart.de> <9185a6$mut$1@nnrp1.deja.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Xref: supernews.google.com comp.lang.ada:3093
Date: 2000-12-13T21:07:01+01:00
List-Id: <comp.lang.ada>

Robert Dewar <robert_dewar@my-deja.com> writes:

> > There a two language-defined checks involved prior
> > to the array comparison.  However, 11.6(5) seems to
> > permit the omission of these checks, but I'm not
> > sure about that.
> 
> Nobody is sure about 11.6 :-)

:-)

> I don't think it applies however. Why not? Because
> the program does indeed depend on the result of this
> comparison. If you did
> 
>   Junk := a.all = b.all;
> 
> and never referenced junk, then you could use
> 11.6(5) to argue that the check should be omitted.

That's one of the simple cases everybody seems to be happy with.

I would argue that a.all and b.all are undefined, but because of their
type, their values can be compared with a well-defined result anyway.