CVS difference for ais/ai-00168.txt

Differences between 1.1 and version 1.2
Log of other versions for file ais/ai-00168.txt

--- ais/ai-00168.txt	1998/09/30 00:17:31	1.1
+++ ais/ai-00168.txt	1998/10/01 00:24:29	1.2
@@ -1,24 +1,107 @@
-!standard 04.06    (00)                               96-11-16  AI95-00168/00
+!standard 04.06    (00)                               98-04-04  AI95-00168/01
 !class binding interpretation 96-11-16
+!status work item 98-04-04
 !status received 96-11-16
 !priority Medium
 !difficulty Easy
-!subject Aliased objects can have discriminants modified
+!subject Aliased objects cannot have discriminants modified
 
-!summary 96-11-16
+!summary 98-04-04
 
+A view conversion may not be used to change the aliased-ness of array
+components.
 
-!question 96-11-16
-
-
-!recommendation 96-11-16
-
-
-!wording 96-11-16
-
-
-!discussion 96-11-16
-
+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 98-04-04
+
+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 98-04-04
+
+(See wording.)
+
+!wording 98-04-04
+
+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 98-04-04
+
+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.
 
 !appendix 96-11-16
 

Questions? Ask the ACAA Technical Agent