CVS difference for ai12s/ai12-0166-1.txt

Differences between 1.6 and version 1.7
Log of other versions for file ai12s/ai12-0166-1.txt

--- ai12s/ai12-0166-1.txt	2016/02/16 03:20:41	1.6
+++ ai12s/ai12-0166-1.txt	2016/03/23 00:40:54	1.7
@@ -1,4 +1,4 @@
-!standard 6.1.1(34/3)                                     15-08-07  AI12-0166-1/03
+!standard 6.1.1(34/3)                                     16-03-22  AI12-0166-1/04
 !standard 9.5(3/3)
 !standard 9.5(7.1/3)
 !class binding interpretation 15-06-17
@@ -62,8 +62,8 @@
 precondition checks and any check for elaboration of the subprogram body are
 performed in an arbitrary order. [It is not specified whether in]{In} a call
 on a protected operation, the checks are performed before [or after]
-starting the protected action.[ For an entry call, the checks are performed
-prior to checking whether the entry is open.]
+starting the protected action. For an entry call, the checks are performed
+prior to checking whether the entry is open.
 
 [Editor's note: This is not required to fix the actual problem, but there
 seems to be no advantage to the variability, either for an implementation
@@ -193,6 +193,39 @@
 caused by making an internal call outside of a protected object. That suggests
 that this is not a very important capability, and making it illegal would be
 an improvement over the current practical situation.
+
+!corrigendum 6.1.1(34/3)
+
+@drepl
+The precondition checks are performed in an arbitrary order, and if any of the
+class-wide precondition expressions evaluate to True, it is not specified
+whether the other class-wide precondition expressions are evaluated. The
+precondition checks and any check for elaboration of the subprogram body are
+performed in an arbitrary order. It is not specified whether in a call on a
+protected operation, the checks are performed before or after starting the
+protected action. For an entry call, the checks are performed prior to checking
+whether the entry is open.
+@dby
+The precondition checks are performed in an arbitrary order, and if any of the
+class-wide precondition expressions evaluate to True, it is not specified
+whether the other class-wide precondition expressions are evaluated. The
+precondition checks and any check for elaboration of the subprogram body are
+performed in an arbitrary order. In a call on a protected operation, the checks
+are performed before starting the protected action. For an entry call, the
+checks are performed prior to checking whether the entry is open.
+
+!corrigendum 9.5(7.1/3)
+
+@dinsa
+If a @fa<name> or @fa<prefix> determines a target object, and the name denotes
+a protected entry or procedure, then the target object shall be a variable,
+unless the @fa<prefix> is for an @fa<attribute_reference> to the Count
+attribute (see 9.9). 
+@dinst
+An internal call on a protected function shall not occur within a precondition
+expression (see 6.1.1) of a protected operation nor within a
+@fa<default_expression> of a @fa<parameter_specification> of a protected
+operation.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent