From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,483a6309b2450e41,start
X-Google-Attributes: gid103376,public
From: gavin@praxis.co.uk (Gavin Finnie)
Subject: Ada 95 case statement incompatibility?
Date: 1996/08/27
Message-ID: <4vv4bs$hb8@erlang.praxis.co.uk>#1/1
X-Deja-AN: 176788783
organization: Praxis plc, Bath, U.K.
newsgroups: comp.lang.ada
Date: 1996-08-27T00:00:00+00:00
List-Id: <comp.lang.ada>



Looking at the differences between Ada 83 and Ada 95, there appears to be an
incompatibility which is not mentioned in Appendix X of the Ada 95 Rationale
nor in the Ada Compatibility Guide (Version 6.0 - is this the latest?)

First recall the rule that if the expression in a case statement is the
name of an object whose subtype is static, the set of choices must cover all
and only the values of the subtype, whereas if the subtype is not static, all
values of the base type must be covered.

Now in Ada 95, the definition of static has been extended to include things
that were not static in Ada 83, for example certain array attributes.
This means that some case statements which are legal in Ada 83 become illegal
in Ada 95.

Consider something like

  type A is array (1..10) of integer;
  subtype S is integer range A'FIRST..A'LAST;  -- static in 95, but not in 83
  x : S;
  ...
  case x is
    when integer'FIRST..3 => ... ;
    when 4..6 => ... ;
    when 7..integer'LAST => ... ;
    -- legal Ada 83 since all values of S'BASE *must* be covered
    -- illegal Ada 95 since S is now static, so only 1 to 10 allowed
  end case;

A similar problem occurs if the expression is a call to a function which
returns a value of a static subtype, since a function call is a name in Ada 95
but not in Ada 83.

In practice, these problems are not likely to occur in many programs since the
usual approach would be to use an 'others' clause to cover values outside the
subtype. However, I am surprised that this issue has not been mentioned in the
Ada 95 documentation.

Gavin Finnie