Re: Constraint checking of actuals passed to Attributes

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

In article <wccitwnmi4r.fsf@world.std.com>,
  Robert A Duff <bobduff@world.std.com> wrote:
> I suppose I could try expressing the intent by example:
>
> If you say:
>
>     Uninit: Integer; -- Uninitialized variable!
>     ...
>     if Uninit < 10 then
>         ...
>
> The condition must be either True or False, or it must raise
> an exception.  It must not destroy other variable's values.
> Inside the if statement, Uninit must evaluate to a value less
> than 10.

Now wait a cotton pickin moment (is that the way that phrase
is spelled? :-)

What does the RM say:

9   If the representation of a scalar object does not represent
a value of the object's subtype (perhaps because the object was
not initialized), the object is said to have an invalid
representation.  It is a bounded error to evaluate the value of
such an object.  If the error is detected, either
Constraint_Error or Program_Error is raised.  Otherwise,
execution continues using the invalid representation.  The rules
of the language outside this subclause assume that all objects
have valid representations.  The semantics of operations on
invalid representations are as follows:

   10  If the representation of the object represents a value of
       the object's type, the value of the type is used.

   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.

Where on earth do you manage to narrow down the result to
raising CE or PE or proceeding normally. It would be absolutely
FINE to terminate the program with an error message, and we
SPECIFICALLY discussed this as an appropriate meaning of
implementation-defined when we discussed this clause.

That's why I dislike this business of divining intent so
intensely. You end up asking the design team what they remember
having in mind, and they may not even remember correctly.

I can't see any possible way to read the "implementation
defined" above [which applies ONLY if you do NOT recognize
the situation and raise CE or PE) as being anywhere NEAR
as restrictive as Bob implies.

For example, the following is quite reasonable:

If an object in a boolean expression has an invalid value,
the result will always be false, regardless of the form
of the expression, e.g. a > 10 and a < 10 will both be
false.

This is perfectly predictable, quite reasonable (think about
NaN's in floating point, and ENTIRELY allowable from the quoted
paragraph read in the most friendly form possible).

In fact I would find a compiler that initialized all
"uninitialized" floating point values to NaN and then
said the predictable behavior was specified by the IEEE
rules for handling NaN's to be a very good implementation
of uninitialized.

Similarly if I was on an IBM 7040, then it would be free to
cause a fatal parity error terminating the program on any
access to an uninitialized variable, and that would be just
fine too (again, very NICE behavior, at least during the
testing phase). The WATFOR compiler used to do this (it used
the hardware diagnostic instruction to set parity wrong on
all uninitialized data).

It was my understanding that we put the words implementation
defined in that paragraph precisely to allow a variety of
possible implementations, all of which are reasonable.


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