CVS difference for ais/ai-00373.txt

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

--- ais/ai-00373.txt	2004/06/08 00:44:48	1.2
+++ ais/ai-00373.txt	2004/06/10 05:39:58	1.3
@@ -1,4 +1,4 @@
-!standard 03.03.01(20)                                 04-06-07  AI95-00373/01
+!standard 03.03.01(20)                                 04-06-08  AI95-00373/02
 !class binding interpretation 04-02-05
 !status received 04-01-17
 !priority Low
@@ -7,10 +7,23 @@
 
 !summary
 
+The "arbitrary order" of component initialization referred to in 3.3.1(20)
+gives the implementation too much freedom. In particular, it allows the
+implementation to choose an ordering which leads to problems with
+uninitialized discriminants, uninitialized access values, etc. This problem
+is reduced, but not eliminated, by imposing additional restrictions on the
+order that an implementation may choose.
+
 !question
 
+The rules of 3.3.1(20) are too lax -- they allow one to refer to
+uninitialized discriminants, uninitialized access values, etc.
+Was this intended? (No.)
+
 !recommendation
 
+(See summary.)
+
 !wording
 
 Replace 3.3.1(18/1 - 20) with
@@ -36,13 +49,12 @@
   if it has an access discriminant value constrained by a per-object
   expression, or if it has an initialization expression which includes a name
   denoting the current instance of the type or denoting an access discriminant.
-  The assignments of the fourth step for any components not requiring late
-  initialization must precede the evaluations of the third step for any
-  components requiring late initialization.
-  If two components both require late initialization, then
-  the assignment of the fourth step for the component occurring earlier
-  in the order of the component declarations must precede the evaluation of
-  the third step for the component occurring later.
+  For the third step above, the assignments to any components not requiring
+  late initialization must precede the initial value evaluations for any
+  components requiring late initialization; if two components both require late
+  initialization, then the assignment to the component occurring earlier
+  in the order of the component declarations must precede the initial value
+  evaluation of the component occurring later.
 
 !example
 
@@ -53,9 +65,9 @@
     function Flag_Init (X : access Inner) return Boolean;
 
     type Inner (Discrim : access Outer) is limited
-	record
-	    Flag : Boolean := Flag_Init (Inner'Access);
-	end record;
+        record
+            Flag : Boolean := Flag_Init (Inner'Access);
+        end record;
 
     type Type_With_Lots_Of_Interesting_Components is
        -- contains tasks, discriminants, access values, protected records,
@@ -63,22 +75,22 @@
        ... ;
 
     type Outer is limited
-	record
-	    F1 : Inner (Outer'Access);
-	    F2 : Type_With_Lots_Of_Interesting_Components;
-	    F3 : Inner (Outer'Access);
-	end record;
+        record
+            F1 : Inner (Outer'Access);
+            F2 : Type_With_Lots_Of_Interesting_Components;
+            F3 : Inner (Outer'Access);
+        end record;
 
     procedure Do_All_Sorts_Of_Things
-		 (Interesting : in out
-		     Type_With_Lots_Of_Interesting_Components) is separate;
+                 (Interesting : in out
+                     Type_With_Lots_Of_Interesting_Components) is separate;
     --
     -- abort task components, dereference access values, etc.
 
     function Flag_Init (X : access Inner) return Boolean is
     begin
-	Do_All_Sorts_Of_Things (X.Discrim.all.F2);
-	return True;
+        Do_All_Sorts_Of_Things (X.Discrim.all.F2);
+        return True;
     end Flag_Init;
 
     Problematic : Outer;
@@ -347,5 +359,19 @@
 I think that Note 6 needs to be stated somewhere, at least in the AARM. But
 it really is something users ought to know, so explicit mention in the
 Standard would be a good idea.
+
+****************************************************************
+
+From: Stephen W Baird
+Sent: Tuesday, June 8, 2004  11:52 PM
+
+> I think that Note 6 needs to be stated somewhere, at least in the AARM. But
+> it really is something users ought to know, so explicit mention in the
+> Standard would be a good idea.
+
+I agree that it belongs at least in the AARM.
+I'm not sure it belongs in the standard because it seems that 13.9.1 already
+covers this. Note the words "and any explicit or default initializations have
+been performed" in 13.9.1(4).
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent