CVS difference for ais/ai-00171.txt

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

--- ais/ai-00171.txt	1998/09/30 23:25:19	1.2
+++ ais/ai-00171.txt	1999/08/20 03:59:44	1.3
@@ -1,5 +1,6 @@
-!standard 03.08    (18)                               98-06-12  AI95-00171/03
+!standard 03.08    (18)                               99-08-17  AI95-00171/04
 !class binding interpretation 98-03-19
+!status Corrigendum 2000 99-08-17
 !status WG9 approved 98-06-12
 !status ARG Approved 11-0-1  98-04-01
 !status received 96-11-16
@@ -7,7 +8,7 @@
 !difficulty Hard
 !subject Elaboration of subtype_indications with per-object constraints
 
-!summary 98-04-16
+!summary
 
 The elaboration of a subtype indication with a per-object constraint
 occurs when an object of the enclosing type is created. This elaboration
@@ -21,7 +22,7 @@
 is not part of a per-object expression, then it must be evaluated once
 for each associated component.
 
-!question 98-03-19
+!question
 
 When does the elaboration of a subtype indication with a per-object
 constraint occur?  What are the actions of such an elaboration?
@@ -86,7 +87,7 @@
 such an association, the expression must be evaluated once for each
 associated component, as prescribed by 3.7.1(12).
 
-!wording 98-04-01
+!wording
 
 Changes are required in 3.3.1(18), 4.3.1(19), 4.8(10), and 9.4(14)
 to state that any subtype indications for components with a per-object
@@ -96,7 +97,7 @@
 needs to account for multiple evaluations of non-per-object expressions
 in the case of named associations in a per-object discriminant constraint.
 
-!discussion 98-04-01
+!discussion
 
 There are two basic problems with the current RM wording regarding
 the elaboration of components with a per-object constraint.  The
@@ -137,8 +138,87 @@
 each expression of the constraint, but the intent is that for a named
 association the expression should be evaluated for each associated
 component.
+
+!corrigendum 3.03.01(18)
+
+@drepl
+@xhang<   3.@tabThe object is created, and, if there is not an initialization
+expression, any per-object expressions (see 3.8) are evaluated
+and any implicit initial values for the object or for its
+subcomponents are obtained as determined by the nominal subtype.>
+@dby
+@xhang<   3.@tabThe object is created, and, if there is not an initialization
+expression, any per-object constraints (see 3.8) are elaborated
+and any implicit initial values for the object or for its
+subcomponents are obtained as determined by the nominal subtype.>
+
+!corrigendum 3.08(18)
+
+@drepl
+Within the definition of a composite type, if a @fa<component_definition> or
+@fa<discrete_subtype_definition> (see 9.5.2) includes a @fa<name> that denotes
+a discriminant of the type, or that is an @fa<attribute_reference> whose prefix
+denotes the current instance of the type, the expression containing the
+@fa<name> is called a @i<per-object expression>, and the constraint being
+defined is called a @i<per-object constraint>. For the elaboration of a
+@fa<component_definition> of a @fa<component_declaration>, if the constraint
+of the @fa<subtype_indication> is not a per-object constraint, then the
+@fa<subtype_indication> is elaborated. On the other hand, if the constraint
+is a per-object constraint, then the elaboration consists of the evaluation
+of any included expression that is not part of a per-object expression.
+@dby
+Within the definition of a composite type, if a @fa<component_definition> or
+@fa<discrete_subtype_definition> (see 9.5.2) includes a @fa<name> that denotes
+a discriminant of the type, or that is an @fa<attribute_reference> whose prefix
+denotes the current instance of the type, the expression containing the
+@fa<name> is called a @i<per-object expression>, and the @fa<constraint> or
+@fa<range> being defined is called a @i<per-object constraint>. For the
+elaboration of a @fa<component_definition> of a @fa<component_declaration> or
+the @fa<discrete_subtype_definition> of an @fa<entry_declaration> for an entry
+family (see 9.5.2), if the @fa<constraint> or @fa<range> of the
+@fa<subtype_indication> or @fa<discrete_subtype_definition> is not a per-object
+constraint, then the @fa<subtype_indication> or @fa<discrete_subtype_definition>
+is elaborated. On the other hand, if the @fa<constraint> or @fa<range> is a
+per-object constraint, then the elaboration consists of the evaluation of any
+included expression that is not part of a per-object expression. Each such
+expression is evaluated once unless it is part of a named association in a
+discriminant constraint, in which case it is evaluated once for each associated
+discriminant.
+
+When a per-object constraint is elaborated (as part of creating an object),
+per-object expressions are evaluated, but other expressions are not evaluated.
+Rather, the values of the expressions evaluated during the elaboration of the
+@fa<component_definition> or @fa<entry_declaration> are used. Any checks
+defined for the @fa<constraint> or @fa<range> are performed, including the
+subtype compabilitity check (see 3.2.2).
+
+!corrigendum 9.05.02(22)
+
+@drepl
+For the elaboration of an @fa<entry_declaration> for an entry family, if the
+@fa<discrete_subtype_definition> contains no per-object expressions (see 3.8),
+then the @fa<discrete_subtype_definition> is elaborated. Otherwise, the
+elaboration of the entry_declaration consists of the evaluation of any
+expression of the @fa<discrete_subtype_definition> that is not a per-object
+expression (or part of one). The elaboration of an @fa<entry_declaration> for a
+single entry has no effect.
+@dby
+The elaboration of an @fa<entry_declaration> for an entry family consists of
+the elaboration or evaluation of the @fa<discrete_subtype_definition> as
+described in 3.8. The elaboration of an @fa<entry_declaration> for a single
+entry has no effect.
+
+!ACATS test
+
+An extensive set of tests check cases where a constraint contains an enclosing
+discriminant in component_definitions (C37213x and C37215x).
+
+C-Tests should be constructed to check that these rules are enforced on
+per-object constraints in task and protected specifications, and that the
+checks are made when the per-object expression contains a attribute whose
+prefix denotes the current instance of the type.
 
-!appendix 96-11-16
+!appendix
 
 !section 3.8(18)
 !subject Elaboration of subtype_indications with per-object constraints
@@ -195,5 +275,44 @@
 
 -Vince Del Vecchio
 vdelvecc@inmet.com
+
+****************************************************************
+
+!from Randy Brukardt  99-08-17
+
+Per-object constraints are mentioned in 3.8(18), 3.3.1(18), 4.3.1(19), 4.8(10),
+9.1(12), 9.4(14), 9.5.2(22), 7.6(12), 7.6.1(9), and 13.14(8).
+3.8(18 is the defining occurrence. The next six all deal with either the
+evaluation or elaboration of per-object constraints. The other three deal with
+other issues (Initialize calls, Finalize calls, and freezing, respectively)
+and do not need changes.
+
+All of 4.3.1(19), 4.8(10), 9.1(12), and 9.4(14) talk in terms of elaborating
+the per-object constraint. If that was properly defined, no changes are
+required in any of these clauses.
+
+The primary problem here is with 3.3.1(18), which does not speak in terms of
+elaborating the per-object constraint (meaning that needed checks aren't done).
+This paragraph was changed to use that terminology.
+
+The secondary problem is no definition of the elaboration of a per-object
+constraint. This was added to 3.8(18). It also was changed to
+insure that evaluation was done multiple times, if needed.
+
+As part of the repairs, I moved the discussion of per-object constraints for
+entries from 9.5.2(22) to 3.8(18), in order to insure that the same semantics
+is given to both. Since this case has to be mentioned (both when defining
+per-object constraint, and when defining elaboration of a per-object constraint)
+leaving it in 9.5.2(22) simply means the same words have to be given a second
+time. (Which increases the errors).
+
+I noticed another problem: a discrete_subtype_definition can be a range, which
+is *not* a constraint. Therefore, I added "range" to the definition of
+per-object constraint (or we'd just have a new hole for the next round to
+patch up).
+
+I think that the last phrase of 3.8(18A) ("including the subtype compabilitity
+check (see 3.2.2).") is redundant, but the AI recommendation seems insistent
+that it be included. I'd be happy to do without it.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent