Re: Constraint checking of actuals passed to Attributes

[Ted Dennison <dennison@telepath.com>]

In article <wccln1a5wh8.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> Ted Dennison <dennison@telepath.com> 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.