Re: Bug in AdaEd???

[rational.com!geneo@uunet.uu.net (Gene Ouye)]

> I (geneo@Rational.COM (Gene Ouye)) responded to someone's question:

[deleted in Robert's response was the definition of a Boolean subtype that
 was constrained to only one value, "True..True", I think, and a declaration
 of "a" to be of that subtype]

>    :        a:= not a;

>   > This SHOULD have raised CONSTRAINT_ERROR.  Just out of curiosity, were
>   > you able to print the value of A after the negation and see FALSE?
>   > Eg, Text_Io.Put_Line ("Value of a => " & Boolean'Image (A));
                                          

eachus@spectre.mitre.org (Robert I. Eachus) responded:

>      The reason that Ada/ED does not check for CONSTRAINT_ERROR is
> that that is the way that "not" is defined in Ada 83 and for that
> matter will be in Ada 9X.  (Operators like "not" work on values of the
> base type so, for example, "A = not A" can never propagate
> CONSTRAINT_ERROR.)

I've looked at this about six different times since it was posted, and I
don't see how this makes a difference.  It's true that the base type of
"a" is Boolean, but when the result of the Boolean expression "not a" is
assigned to the object "a", the result is outside the range of the
subtype to which "a" belongs.  I can see how the expression "not a"
would never raise an exception (because "not" operates on the base type
(Boolean) and returns a value of the base Boolean type), but it seems
that assigning it to something belonging to a constrained subtype should
raise Constraint_Error (except possibly in cases where the compiler can
assume that the value to be assigned is invalid, as described below).
Your Boolean expression "A = not A" should not propagate Constraint_Error
but instead should evaluate to False.

In fact this seems little different from the following:

    declare

        I : Natural := 5;

    begin                               

        -- other statements could go here that muck with I so that it
        -- is not trivially optimized away in accordance with RM 11.6(7)
        -- as described later in Robert's response.
    
        I := -I; -- Shouldn't this raise CONSTRAINT_ERROR?

    end;
        

>      Now if you read RM 11.6(7), compilers are not only allowed, but
> encouraged to remove predefined operations whose only possible effect
> is to raise an exception.  "A predefined operation need not be invoked
> at all, if its only possible effect is to propagate a predefined
> exception." (RM 11.6)  So not raising CONSTRAINT_ERROR is appropriate.
> (Incidently, we are still working on a better version of (old))
> section 11.6 for Ada 9X.  Coming up with a rule which allows
> appropriate optimizations without surprising the user is tough.)

>     However, when the Ada 83 RM was written, no one thought of the
> possibility of arrays whose component is subtype of Boolean.
> Technically there is in Ada 83 a check on values of type Boolean done
> on the assignment, but for arrays there is no subtype check done for
> arrays of Booleans.  AI-535 fixed this, but well after the last Ada/ED
> validation.

On first reading, RM 11.6(7) does seem to be a valid reason for a
compiler to do nothing with "a := not a;" as it was originally posted
(but see my later comments), but what about the following:

  with Calendar, Text_Io; use Calendar;
  procedure Will_I_Die is

      subtype Only_True is Boolean range True .. True;
      I_Should_Be_Always_True : Only_True;

  begin

      I_Should_Be_Always_True := (Day (Clock) = 21);
      I_Should_Be_Always_True := not I_Should_Be_Always_True;
      Text_Io.Put_Line ("Nope, didn't die!!");

  exception
      when Constraint_Error =>
          Text_Io.Put_Line ("OK, I got Constraint_Error, is today the 21st?");
  end Will_I_Die;

On any day except the 21st, this program should raise Constraint_Error
on the first statement.  If Ada/ED is using RM 11.6(7) as a reason for
not raising Constraint_Error in the original poster's example, it should
still raise Constraint_Error when the second assignment is executed (on
the 21st, of course!), no?  Or is Ada/ED smart enough to catch this
inevitable exception too?

I don't have Ada/ED, so I can't try this myself to see.

One more question on RM 11.6(7): isn't it supposed to be saying that the
operation need not be invoked (because we know the operation will result
in an exception), but that the exception should still be raised (ie, the
statement may be replaced by an explicit "raise" statement)?

> --

>                     Robert I. Eachus

> with Standard_Disclaimer;
> use  Standard_Disclaimer;
> function Message (Text: in Clever_Ideas) return Better_Ideas is...

--
Gene Ouye (geneo@rational.com)    Rational, Bethesda, MD, USA
(301) 897-4014