Version 1.8 of ais/ai-00168.txt

Unformatted version of ais/ai-00168.txt version 1.8
Other versions for file ais/ai-00168.txt

!standard 04.06 (12)          99-08-31 AI95-00168/04
!standard 03.07.01 (07)
!class binding interpretation 96-11-16
!status Corrigendum 2000 99-07-27
!status WG9 approved 99-06-12
!status ARG Approved 7-0-0 98-10-09
!status work item 98-04-04
!status received 96-11-16
!priority Medium
!difficulty Easy
!qualifier Error
!subject Aliased objects cannot have discriminants modified
!summary
A view conversion of an array object is illegal if the target subtype and the operand do not have both aliased components or both non-aliased components.
A discriminant constraint for a general access type is illegal if the designated subtype is a private type with default discriminants, but the partial view has no discriminants.
!question
Consider the following code fragment:
package P is pragma Elaborate_Body; type T is private; A : constant T; private type T (D : Integer := 0) is null record; type Ptr is access all T; A : constant T := (D => 1); end P;
with P; package Q is type A1 is array (1 .. 10) of aliased P.T; type A2 is array (1 .. 10) of P.T; X : A1; end Q;
with P, Q; procedure R is procedure S (Y : in out Q.A2) is begin Y (1) := P.A; end; begin S (Q.A2 (Q.X)); -- This call will change the discriminant of Q.X (1) end;
This example illustrates a case where it is possible to change the discriminant of an aliased component of an object, which is supposed to be forbidden.
!recommendation
(See wording.)
!wording
Add the following clause after RM95 4.6(12):
In a view conversion for an array type, the target type and the operand type shall either both have aliased components, or both have non-aliased components.
Add the following clause after RM95 3.7.1(7):
A discriminant_constraint is not allowed in a subtype_indication whose subtype_mark denotes a general access subtype whose designated subtype is a private type with defaulted discriminants, if the partial view of the private type has no discriminants.
!discussion
The problem (1) comes from the fact that it is possible to use a view conversion to convert an array object with aliased components to an array type with non-aliased components. Such a conversion must be disallowed.
At the Henley meeting, the following case was also discussed:
with Q; package body P is PT : Ptr (0) := Q.X (1)'access; begin Q.X := (others => (D => 2)); -- Changes the discriminant of Q.X (2) end P;
The root of problem (2) is that the partial view of P.T is constrained, but the full view isn't. This causes privacy problems when applying the following rule:
"if a component_definition contains the reserved word aliased and the type of the component is discriminated, then the nominal subtype of the component shall be constrained." (RM95 3.6(11))
One way to fix this problem would be to require a component-by-component check on the assignment to Q.X, but that would be very expensive. Moreover, a compile-time check would clearly be better than a run-time check.
Aliased-ness of the components is not really what is causing trouble, though. It is really the existence of a general access type, and in fact of a discriminant constraint on such an access type, which causes trouble. Thus, forbidding such a constraint seems like the right solution, especially considering that constraints on access types are not a terribly useful feature.
!corrigendum 3.07.01(7)
Insert after the paragraph:
A discriminant_constraint is only allowed in a subtype_indication whose subtype_mark denotes either an unconstrained discriminated subtype, or an unconstrained access subtype whose designated subtype is an unconstrained discriminated subtype.
the new paragraph:
A discriminant_constraint is not allowed in a subtype_indication whose subtype_mark denotes a general access subtype whose designated subtype is a private type with defaulted discriminants, if the partial view of the private type has no discriminants.
!corrigendum 4.06(12)
Insert after the paragraph:
the new paragraph:
In a view conversion for an array type, the target type and the operand type shall either both have aliased components, or both have non-aliased components.
!ACATS test
B-Tests should be created for each rule. (There must be two, since the rules are in different sections.)
!appendix

!section 4.6(00)
!subject Aliased objects can have discriminants modified
!reference RM95-4.6
!reference RM95-6.4.1 (16,17)
!from Stephen Michell 96-10-12
!keywords constrained object aliased change of discriminat
!reference 96-5720.a Steve Michell 96-10-12>>
!discussion

Consider the following code fragment

       procedure acc_cvt2 is
         package P is
           type T is private;
           a: constant T;
           b: constant T;
         private
           type T( X: integer := 0 ) is null record;
           a: constant T := ( X => 1 );
           b: constant T := ( X => 2 );
         end P;
         type A is array( 1 .. 10) of aliased P.T;
         type B is array( 1 .. 10) of P.T;
         X : A := (1..10 => P.a);
         procedure Q( Y : in out B ) is
         begin
           Y(1) := P.B;
         end Q;
       begin
         Q(B(X));
       end ACC_CVT2;

Object X is constrained because it is an array of aliased records, even
though unaliased objects of such a type would be unconstrained. The call
Q(B(X)) is a view conversion by 4.6(5). The remaining rules in 4.6
do not appear to cover the case shown above, but it appears that a view
conversion between an unconstrained and constrained view of an object
should be illegal.

****************************************************************


Questions? Ask the ACAA Technical Agent