Version 1.1 of acs/ac-00133.txt

Unformatted version of acs/ac-00133.txt version 1.1
Other versions for file acs/ac-00133.txt

!standard 5.4(6-10)          06-11-06 AC95-00133/01
!standard 4.9
!class confirmation 06-11-06
!status received no action 06-11-06
!status received 06-06-30
!subject Case statement anomolies

From: Adam Beneschan
Date: Friday, June 30, 2006 12:33 PM

While looking into a recent comp.lang.ada post, I found that the
language rules have some counter-intuitive implications (if I
understand the rules correctly).  I'm not suggesting any language
change, but it's been suggested that I post this example to the
mailing list.

   procedure Test713 is
      type Enum is (e1, e2, e3, e4, e5);
      subtype Enum_Subtype is Enum range e2..e4;
      type Arr is array (Enum_Subtype) of integer;
      type Rec is record
         F1 : Arr;
      end record;

      X : Arr;
      Y : Rec;
      type Access_Arr is access Arr;
      Z : Access_Arr;
      for J in X'Range loop        -- J's subtype is static
         case J is
           when e2..e4 => null;
         end case;
      end loop;

      for K in Y.F1'Range loop     -- K's subtype is not static
         case K is
           when e2..e4 => null;
         end case;
      end loop;

      for Q in Z'Range loop        -- Q's subtype is not static
         case Q is
           when e2..e4 => null;
         end case;
      end loop;
   end Test713;

Although it would seem that X, Y.F1, and Z.all all have type Arr, and
thus their bounds should all be the same (E2..E4), the first "case"
statement above is legal (and it would be illegal to add choices for
E1 and E5); while the last two case statements are illegal unless you
add choices that cover E1 and E5.

The reason is that 4.9(14-17) says that X statically denotes an
entity, while Y.F1 and Z do not; 4.9(8) then applies (to 'First and
'Last, which is what 'Range is equivalent to), to say that X'Range is
a static subtype but Y.F1'Range and Z'Range are not; and this affects
what choices are are accepted or required for the CASE statement

This apparently has tripped some people up.  A CASE statement similar
to the illegal examples above showed up in GtkAda, and was not caught
due to a compiler bug; when a later version of the compiler didn't
compile the code, the c.l.a poster who tried to compile it assumed
that a new bug had been introduced in the compiler.

Of course simply using Arr'Range in all of the above cases would work.


Questions? Ask the ACAA Technical Agent