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.3 required=5.0 tests=BAYES_00,INVALID_MSGID, MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,e8c8d1c63ffacf0d X-Google-Attributes: gid103376,public From: Ted Dennison Subject: Re: Constraint checking of actuals passed to Attributes Date: 2000/05/16 Message-ID: <8fs6bm$qpv$1@nnrp1.deja.com>#1/1 X-Deja-AN: 624184824 References: <391250A8.99D1585C@hotmail.com> <39171B69.2F983487@averstar.com> <8f93lm$1es$1@nnrp1.deja.com> <8f9snr$vbr$1@nnrp1.deja.com> <391C543F.83B2A408@averstar.com> <8fhnnj$ltd$1@nnrp1.deja.com> <8fhtbt$sb4$1@nnrp1.deja.com> X-Http-Proxy: 1.0 x41.deja.com:80 (Squid/1.1.22) for client 204.48.27.130 Organization: Deja.com - Before you buy. X-Article-Creation-Date: Tue May 16 19:08:52 2000 GMT X-MyDeja-Info: XMYDJUIDtedennison Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.7 [en] (WinNT; I) Date: 2000-05-16T00:00:00+00:00 List-Id: In article , Robert A Duff wrote: > Ted Dennison writes: > > Can you? The relevant section in 13.9.1 only mentions aborted > > assignements and parameters passed to imported procedures. > > Well, for address clauses, I guess I should have said just "cause > erroneousness". If it can do that, then it can do any other bad thing > you can name, so it's kind of silly to argue about whether it can cause > abnormal values. 13.3(13) says it can be erroneous. That just said that the address has to be "valid", not the value at that address. So I had interpreted that to mean that the address had to be within the program's adddress space, and perhaps allocated. For instance, on DOS it can't refer to an unallocated I/O memory location. In VMS, it can't have the high address bit set, etc. After all, one could argue that any address on the stack is "valid". Some may not contain valid values for type Foo, but the addresses themselves are valid. > > too. Perhaps my problem is that I'm missing where "abmormal" is > > truly defined. > > Well, I was going to admonish you to look it up in the index, but I > see the index is incomplete in this case. :-( :-) Thanks for checking. I *did* try that first. > I suggest you get the plain-ascii version of the AARM, and search for > abnormal. Done. 7.6.1(2) sort of defines it by context. The whole reason for this LRM-diving expedition on my part was to try to figure out how exactly the 95 LRM views the address clause type-hosing technique. In the old Ada it used be erronious. My reading of what I have seen in the LRM says that it is not defined by the language to ever be erronious, as long as the addressee object exists and any extra bytes the addressor type needs also happen to be in existing objects. Since there's no way to guarantee the latter, then one could say its perfectly OK, as long as the addressee object is at least as large as the addressor. Based on your text above about the meaning of 13.3(13), I'm guessing you'd say that the execution can be erronious if the value at that address is not valid for the addressor's type. However, using 13.3(13) for this purpose seems inconvienent, because it is only talking about the addressor object. So technically its not defined as erronious if the program causes the value to be invalid for the addressee type by assigning that value via the addressor type. -- T.E.D. http://www.telepath.com/~dennison/Ted/TED.html Sent via Deja.com http://www.deja.com/ Before you buy.