Re: Constraint checking of actuals passed to Attributes

[Robert Dewar <robert_dewar@my-deja.com>]

In article <39171B69.2F983487@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:

> but are required to at least "survive" the uninitialized
> variable situation in Ada 95. This is because the first two
> are "erroneous" situations whereas the last one is merely a
> "bounded error."  This means that in the first two cases,
> anything could happen (incineration of disk drive, etc.),
> whereas in the uninitialized case, Program_Error,
> Constraint_Error, or producing some arbitrary value as the
> result would be acceptable.

A lot of things would be acceptable, including incineration
of disk drives. Why? let's read the RM:

   11  If the representation of the object does not represent a
       value of the object's type, the semantics of operations
       on such representations is implementation-defined, but
       does not by itself lead to erroneous or unpredictable
       execution, or to other objects becoming abnormal.

Unfortunately, implementation-defined is a HUGE hole, through
which almost any truck can be driven. OK, so it is probably
not acceptable for an implementation to say:

  In this implementation, the semantics of such operations
  is erroneous.

But I can't see anything wrong in a statement that says

  In this implementation, the semantics of such operations
  is that the following horrible things may happen:

    Long list of horrible consequences, which does not
    explicitly mention erroneousness or abnormal values,
    but whose consequences are equally severe.

OK, Bob and Tuck will argue that this does not meet the
"intent" of the authors in writing the above statement.

Arguments from intent are always suspect, but never more
so than when the intent is vague and unclear. I really
cannot see the thoughts behind trying to carefully bound
the effects of an error, and then allowing one of the
possible effects to be implementation defined.

The notion of "anything short of erroneous" is definitely
not one that is well defined, or testable.

Ken -- time for another of your complaints about dubious
requirements :-)





>
> In Ada 83, using uninitialized variables is erroneous as well,
> so some compilers out there might still misbehave on them due
> to bugs or ancestry.
>
> > Opinions with ARM references most welcome! :-)
>
> RM95 A.13(17) -- unchecked binary input
> RM95 13.9(11)/13.9.1(8) -- unchecked conversion/abnormality
> RM95 13.9.1(9-11) -- uninitialized variable bounded error
>
> >
> >   Matt
>
> --
> -Tucker Taft   stt@averstar.com
http://www.averstar.com/~stt/
> Technical Director, Commercial Division, AverStar (formerly
Intermetrics)
> (http://www.averstar.com/services/IT_consulting.html)
Burlington, MA  USA
>


Sent via Deja.com http://www.deja.com/
Before you buy.