CVS difference for ais/ai-00373.txt

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

--- ais/ai-00373.txt	2005/08/05 04:36:42	1.9
+++ ais/ai-00373.txt	2005/10/31 05:18:38	1.10
@@ -1,4 +1,4 @@
-!standard 03.03.01(08)                                 05-07-20  AI95-00373/07
+!standard 03.03.01(08)                                 05-10-12  AI95-00373/08
 !standard 03.03.01(18/1)
 !standard 03.03.01(19)
 !standard 03.03.01(20)
@@ -49,7 +49,7 @@
 
   A component of an object is said to *require late initialization*
   if it has an access discriminant value constrained by a per-object
-  expression, or if it has an initialization expression which includes a name
+  expression, or if it has an initialization expression that includes a name
   denoting the current instance of the type or denoting an access discriminant.
 
 Replace 3.3.1(18/1 - 20) with
@@ -239,7 +239,7 @@
 @dinst
 A component of an object is said to @i<require late initialization>
 if it has an access discriminant value constrained by a per-object
-expression, or if it has an initialization expression which includes a name
+expression, or if it has an initialization expression that includes a name
 denoting the current instance of the type or denoting an access discriminant.
 
 !corrigendum 3.3.1(18/1)
@@ -580,5 +580,88 @@
 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).
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005  12:33 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+3.3.1(18.a) says:
+
+    18.a  Discussion: For a per-object constraint that contains some
+          per-object expressions and some non-per-object expressions, the
+          values used for the constraint consist of the values of the
+          non-per-object expressions evaluated at the point of the
+          type_declaration, and the values of the per-object expressions
+          evaluated at the point of the creation of the object.
+
+Is this still correct, given new rules about per-object constraints?
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Monday, June 6, 2005  4:33 PM
+
+I would say it is still true.  We might have changed the
+order in which things are done, but the notion of what
+is a "per-object constraint" hasn't changed.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005  3:41 AM
+
+I agree.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, June 6, 2005  12:34 PM
+
+I'm using draft 11.8 of the [A]ARM.
+
+3.3.1(20.h/2):
+
+    20.h/2 It is possible for there to be more than one component that
+          requires late initialization. In this case, the language can't
+          prevent problems, because all of the components can't be the last
+          one initialized. In this case, we specify the order of
+          initialization for components requiring late initialization; by
+          doing so, programmers can arrange their code to avoid accessing
+          uninitialized components, and such arrangements are portable. Note
+          that if the program accesses an uninitialized component, 13.9.1
+          defines the execution to be erroneous.
+                                      ^^^^^^^^^
+Shouldn't that be "bounded error"?
+
+****************************************************************
+
+From: Stephen W Baird
+Sent: Monday, June 6, 2005  2:54 PM
+
+> Shouldn't that be "bounded error"?
+
+No; I think that "erroneous" is correct here.
+
+13.9.1(4) states that an object is not guaranteed to be normal until "any
+explicit or default initializations have been performed".
+13.9.1(8) states that "it is erroneous to evaluate ... an abnormal
+object".
+
+Note that we're not just talking about invalid scalars here - we're
+talking about uninitialized access values, tasks, discriminants, etc.
+
+****************************************************************
+
+From: Pascal Leroy
+Sent: Tuesday, June 7, 2005  3:25 AM
+
+> Shouldn't that be "bounded error"?
+
+I believe it is definitely "erroneous", since we are talking accessing
+discriminants before they have been initialized and other very nasty
+things here.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent