Inconsistencies with Ada 95

1 — The awkward situations regarding access types, discriminants and constraints discussed in 3.5, can also give rise to obscure inconsistencies.

Unconstrained aliased objects of types with discriminants with defaults are no longer constrained by their initial values. This means that a program that raised Constraint_Error in Ada 95 because of attempting to change the discriminants will no longer do so.

Thus consider item 4 in the previous section. We had

type Int_Ptr is access all Integer;
Obj: aliased T;    -- mutable object
Dodgy: Int_Ptr := Obj.Comp'Access;    -- take care
...
Obj:= (Disc => True);    -- Comp gone

We noted that in Ada 2005, the assignment statement to Dodgy is illegal because we cannot write Obj.Comp'Access. The assignment to Obj is itself permitted because we now know that there cannot be any dodgy pointers. Suppose that the assignment to Dodgy is removed. Then in Ada 95, the assignment to Obj will raise Constraint_Error but it will not in Ada 2005. It is extremely unlikely that any correct program relied upon this behaviour. (AI-363, 3.3.1(33.f) and 3.10(26.d))

A related situation applies with allocators where the allocated type is a private type with hidden discriminants. This is also illustrated by an earlier example where we had

with P;  use P;
procedure Do_It is
   A: T;
   B: T_Ptr := new T;
   C: T_Ptr := Evil;
begin
   A := Flip(A);
   B.all := Flip(B.all);    -- Constraint_Error in Ada 95, not in 2005
   C.all := Flip(C.all);
end Do_It;

The assignment to B.all raises Constraint_Error in Ada 95 but not in Ada 2005 as explained above. Again it is extremely unlikely that any correct program relied upon this behaviour. (AI-363, 4.8(20.f))

2 — In Ada 2005 the categorization of certain wide characters is changed. As a consequence Wide_Character'Wide_Value and Wide_Character'Wide_Image will change in some rare situations. A further consequence is that for some subtypes S of Wide_Character the value of S'Wide_Width is different. But the value of Wide_Character'Wide_Width itself is not changed. (AI-285, 3.5.2(9.h) and AI-395, 3.5.2(9.i, j))

3 — There is an interesting analogy to incompatibility number 2 which concerns adding further entities to existing predefined packages. If we add further entries to Standard itself then an inconsistency is possible. Thus if an additional entity More is added to the package Standard and an existing program has a package P with an existing entity More and a use clause for P then, in Ada 2005, references to More will now be to that in Standard and not that in P. In the most unlikely event that the program remains legal, it will behave differently. The only such identifiers added to Standard are Wide_Wide_Character and Wide_Wide_String so this is extremely unlikely. (AI-285, 3.5.2(9.k) and 3.6.3(8.g))

4 — Access discriminants and non-controlling access parameters no longer exclude null in Ada 2005. A program that passed null to these will behave differently.

The usual situation is that Constraint_Error will be raised within the subprogram when an attempt to dereference is made rather than at the point of call. If the subprogram has no handler for Constraint_Error then the final effect will be much the same.

But clearly it is possible for the behaviour to be quite different. For example, the access value might not be dereferenced or the subprogram might have a handler for Constraint_Error which does something unusual. And there might even be a pragma Suppress for the check in which case the program will become erroneous.

See 3.2 for an example. (AI-231, 3.10(26.c))

5 — The lower bound of strings returned by functions Expanded_Name and External_Name (and wide versions) in Ada.Tags are defined to be 1 in Ada 2005. Ada 95 did not actually define the value and so if an implementation has chosen to return some other lower bound such as 77 then the program might behave differently. (AI-417, 3.9(33.c)) See also 9.2.2 item 4 below.

Rationale for Ada 2005

9.1.2 Inconsistencies with Ada 95