Re: Constraint checking of actuals passed to Attributes

[Tucker Taft <stt@averstar.com>]

Keith Thompson wrote:
> ...
> If I understand the context of this example correctly, the intent is
> to make these guarantees if Uninit is merely uninitialized, but not if
> it's abnormal (say, if an assignment to it was disrupted; see
> RM95-13.9.1).  The standard doesn't require bizarre things to happen
> under such circumstances, it merely withdraws its usual guarantee that
> bizarre things won't happen.  If the underlying hardware has no
> abnormal representations for type Integer, Integers will never become
> abnormal ("Whether or not an object actually becomes abnormal in these
> cases is not specified.")
> 
> This kind of thing is more likely to show up (on most systems) for
> things like composite objects with corrupted descriptors.  The most
> plausible scenario for type Integer that I can think of is a system
> that represents an integer as a floating-point value with the exponent
> set to zero (I'm not sure whether Ada allows this); something like a
> floating-point NaN would then be an abnormal value for type Integer.
> A less plausible scenario is
> an integer with the low-order bit set to 0.5.
> 
> I suppose the real requirement being imposed here is that, if the
> underlying system has "abnormal" representations for a given type, the
> Ada implementation must guarantee that an uninitialized variable isn't
> set to one of those representations.

That wasn't the problem we worried about when inventing the "invalid"
versus "abnormal" distinction.  Imagine the following:

    X : Very_Long_Integer range -5..5;
    Y : Very_Long_Integer range -5..5 := 4;
    A : array(Very_Long_Integer range -5..5) of Integer;

   ...

    A(X) := 37;  -- X might be invalid here, but not abnormal.
                 -- the implementation should not trash random memory
    A(Y) := 37;  -- Y is valid here (and normal)
    Y := -5;  -- imagine abort or other "disruption" happens in middle
           -- of this multi-word assignment, and Y ends up with a weird value
           -- like -4 billion (due to setting the high 32 bits to -1,
           -- while leaving the low 32 bits as +4).
           -- If then in finalization code or an exception handler
           -- we write "A(Y) := 36".  Y might be abnormal and the 
           -- implementation is free to trash random memory.

In other words, abnormal means out of range due to disruption, or
"bad" binary input or unchecked conversion,
whereas invalid means out of range due to lack of initialization or
other "normal" behavior.  The implementation is supposed to "survive"
out-of-range due to "normal" behavior (e.g. forgetting an initializer)
but not due to one of these "bad" things like disruption, etc.
Without this distinction, the implementation would have to assume
the worst about the value stored in a constrained object in many
more cases, making it that much harder to eliminate redundant range checks.

> 
> --
> Keith Thompson (The_Other_Keith) kst@cts.com  <http://www.ghoti.net/~kst>
> San Diego Supercomputer Center           <*>  <http://www.sdsc.edu/~kst>
> Welcome to the last year of the 20th century.

-- 
-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