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

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0179-1.txt

--- ai12s/ai12-0179-1.txt	2016/11/11 01:37:13	1.4
+++ ai12s/ai12-0179-1.txt	2016/11/11 02:24:56	1.5
@@ -1,4 +1,4 @@
-!standard 1.1.3(17/3)                                  16-11-10  AI12-0179-1/03
+!standard 1.1.3(17/3)                                  16-11-11  AI12-0179-1/04
 !standard 11.4.2(23.1/3)
 !class binding interpretation 16-01-04
 !status Amendment 1-2012 16-11-10
@@ -30,8 +30,9 @@
 
 Add after 1.1.3(17/3):
 
-The implementation of a language-defined unit shall abide by all postconditions
-and type invariants specified for the unit International Standard (see 11.4.2).
+For an implementation that conforms to this Standard, the implementation of a
+language-defined unit shall abide by all postconditions and type invariants
+specified for the unit International Standard (see 11.4.2).
 
 Add after 11.4.2(23.1/3):
 
@@ -55,7 +56,7 @@
  
 AARM To Be Honest: Evaluation of any expression might raise Storage_Error.
  
-AARM Reason: This allows the standard to express semantic requirements as
+AARM Reason: This allows the Standard to express semantic requirements as
 postconditions or invariants (which are invariably clearer than English
 prose would be) while keeping it clear that failing the assertion check (or
 any other run time check) is not conforming behavior.
@@ -87,6 +88,42 @@
 apply to the client or to the implementation), so we do not include them here
 and suggest that the Standard avoid using them.
 
+!corrigendum 1.1.3(17/3)
+
+@dinsa
+An implementation conforming to this International Standard may provide
+additional aspects, attributes, library units, and pragmas. However, it shall
+not provide any aspect, attribute, library unit, or pragma having the same
+name as an aspect, attribute, library unit, or pragma (respectively) specified
+in a Specialized Needs Annex unless the provided construct is either as
+specified in the Specialized Needs Annex or is more limited in capability than
+that required by the Annex. A program that attempts to use an unsupported
+capability of an Annex shall either be identified by the implementation before
+run time or shall raise an exception at run time. 
+@dinst
+For an implementation that conforms to this Standard, the implementation of
+a language-defined unit shall abide by all postconditions
+and type invariants specified for the unit by this International Standard
+(see 11.4.2).
+
+!corrigendum 11.4.2(23.1/3)
+
+@dinsa
+It is a bounded error to invoke a potentially blocking operation (see 9.5.1)
+during the evaluation of an assertion expression associated with a call on, or
+return from, a protected operation. If the bounded error is detected,
+Program_Error is raised. If not detected, execution proceeds normally, but if
+it is invoked within a protected action, it might result in deadlock or a
+(nested) protected action. 
+@dinss
+@s8<@i<Implementation Requirements>>
+
+Any postcondition expression or type invariant expression occurring in the
+specification of a language-defined unit is enabled (see 6.1.1 and 7.3.2).
+
+The evaluation of any such postcondition or type invariant expression shall
+either yield True or propagate an exception from a @fa<raise_expression> that
+appears within the assertion expression.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent