Ada 95 case statement incompatibility?

Ada 95 case statement incompatibility?

[Gavin Finnie]

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

Re: Ada 95 case statement incompatibility?

[Michael F Brenner]

Another difference between 83 and 95 that was not documented is the
later rule that generics instantiated with signed numbers are 
incompatible with generics instantiated with unsigned numbers. This
makes the systems programming of device drivers almost impossible to
program compatibly between 83 and 95, and also (ultimately) led to
the decision that we don't have access to the upper bit of an 
n-bit signed or unsigned number during conversions. This loss of a bit
can have an efficiency effect, as well as the workarounds it forces
one to place in one's code. For example, in one current Ada-95 compiler,
the unchecked conversion one would think of to work around the problem
actually generates code! The original Ada 9X requirement to handle
and give the systems programmer access to all the bits was not handled here.
Those Ada 83 implementations that gave unsigned numbers (by overloading
modular operations onto a signed number type) are not compatible in
either regular code (documented in the list of incompatibilities) or 
generically (not documented in the list of incompatibilities).

Re: Ada 95 case statement incompatibility?

[Robert Dewar]

Michael says

"Another difference between 83 and 95 that was not documented is the
later rule that generics instantiated with signed numbers are
incompatible with generics instantiated with unsigned numbers."

This is wrong. Ada 83 did not have unsigned numbers. Any legal provisions
for some approximation of unsigned numbers in Ada 83 compilers are 100%
compatible with Ada 95. Ada 95 provides a completely new feature, modular
types, that you can use if you want, but the addition of this feature
does not create any incompatibilities!

Re: Ada 95 case statement incompatibility?

[Norman H. Cohen]

In article <4vvmra$k3t@linus.mitre.org>, mfb@mbunix.mitre.org
(Michael F Brenner) writes: 

|> Another difference between 83 and 95 that was not documented is the
|> later rule that generics instantiated with signed numbers are
|> incompatible with generics instantiated with unsigned numbers.

But there were no unsigned types in the Ada-83 standard!  It is true that
some implementations provided implementation-defined (signed) integer
types whose operators were redefined to behave in roughly the same manner
as Ada-95 modular types.  However, since these types were
implementation-defined, an Ada-83 program using them was not portable
even to other Ada-83 compilers.  The fact that they may not be portable
to some Ada-95 compilers either is neither a surprise nor an
incompatiblity between the Ada-83 and Ada-95 standards!

There is nothing in Ada-95 to prevent vendors who provided these signed
types with modular behavior in their Ada-83 compilers from also providing
them in their Ada-95 compilers, in addition to the modular types required
by the Ada-95 standard.  Such types are redundant in the presence of
Ada-95 modular types, but provide a path for customers to migrate their
legacy Ada-83 code to Ada 95.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: Ada 95 case statement incompatibility?

[Robert Dewar]

Norman says

"There is nothing in Ada-95 to prevent vendors who provided these signed
types with modular behavior in their Ada-83 compilers from also providing
them in their Ada-95 compilers, in addition to the modular types required
by the Ada-95 standard.  Such types are redundant in the presence of
Ada-95 modular types, but provide a path for customers to migrate their
legacy Ada-83 code to Ada 95.
"
Indeed, for example, in the VMS port of GNAT, we have added a pragma
Extend_System that allows you to add implementation specific features
to package System, and we use this feature to allow a user to put all
the standeard DEC unsigned support into system (as well as all the other
DEC system stuff).

Re: Ada 95 case statement incompatibility?

[Robert Dewar]

Gavin says

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

Exactly, it is quite hard to believe that you found this in a real program,
surely you just figured it out from reading.

There are quite a lot of obscure legality incompatibilities of this type
if you start hunting. The compatibility guide is limited to things that
one expects to be a problem in real life!

Re: Ada 95 case statement incompatibility?

[Gavin Finnie]

In response to my original posting, dewar@cs.nyu.edu (Robert Dewar) writes:
>Exactly, it is quite hard to believe that you found this in a real program,
>surely you just figured it out from reading.

Yes, you're right.
I did figure it out from reading and constructed the example to try it out.

>There are quite a lot of obscure legality incompatibilities of this type
>if you start hunting. The compatibility guide is limited to things that
>one expects to be a problem in real life!

Hmm, it's no big deal but I would say my example, although contrived, was no
more obscure than some of the things already in Rationale X.6.2 which are
"considered to be unlikely in normal programs".

Gavin Finnie

Re: Ada 95 case statement incompatibility?

[Robert A Duff]

In article <4vv4bs$hb8@erlang.praxis.co.uk>,
Gavin Finnie <gavin@praxis.co.uk> wrote:
>  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;

Yes, we missed that one.

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

This one is documented in the AARM (see 5.4(18.b)), which is where the
language design team put such information.  It may have gotten added
rather late in the process, causing it to be missed in the Rat and the
Compat Guide.

>In practice, these problems are not likely to occur in many programs ...

Indeed.

- Bob