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

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

--- ai12s/ai12-0159-1.txt	2015/03/28 00:13:16	1.4
+++ ai12s/ai12-0159-1.txt	2015/03/31 22:14:24	1.5
@@ -1,6 +1,7 @@
-!standard 3.5.9(6)                                     15-03-27  AI05-0159-1/03
+!standard 3.5.9(6)                                     15-03-31  AI05-0159-1/04
+!standard 4.1.4(9/4)
 !standard 6.1.1(7/4)
-!standard 6.1.1(26.4/4)
+!standard 6.1.1(26.2/4)
 !standard 6.1.1(37/4)
 !standard 6.1.1(38/4)
 !standard 6.3.1(12/4)
@@ -12,10 +13,9 @@
 !standard 6.4.1(6.29/4)
 !standard 6.4.1(13.1/4)
 !standard 7.3.2(5/4)
-!standard 7.3.2(10/4)
 !standard 7.3.2(21/4)
 !standard 7.3.2(22.1/4)
-!standard 11.3(2/4)
+!standard 11.3(3/4)
 !standard 11.3(3.2/4)
 !standard 11.3(4.1/4)
 !standard A(3.1/4)
@@ -74,7 +74,7 @@
 (12) In 6.4.1(13.1-4/4), the "except in the following case:" is awkward
 and ambiguous. Can we do better? (Yes.)
 
-(13) 6.4.1(26.4/4) says "is of an anonymous access, ...". Is the word "type"
+(13) 6.4.1(26.2/4) says "is of an anonymous access, ...". Is the word "type"
 missing here? (Yes.)
 
 (14) 6.1.1(37/4) starts out with
@@ -184,7 +184,7 @@
 
 (9)
 
-Modify 6.1.1(7/4): [Ploedereder]
+Modify 6.1.1(7/4):
 
 Within the expression for a Pre'Class or Post'Class aspect for a 
 primitive subprogram S of a tagged type T, a name that denotes a 
@@ -217,8 +217,8 @@
 expression is well-defined for any type descended from T.].
 Add an AARM note:
 
-Reason: This ensures that the expression is well-defined for
-any type descended from T.
+Reason: The rules for Type_Invariant'Class ensure that the invariant
+expression is well-defined for any type descended from T.
 
 (10)
 
@@ -250,7 +250,7 @@
 
 (13)
 
-Modify 6.1.1(26.4/4):
+Modify 6.1.1(26.2/4):
 
  * If X is of an anonymous access {type} defined by an access_definition
    A then
@@ -390,6 +390,330 @@
 @dinst
 The @fa<simple_expression> of a @fa<digits_constraint> is expected to be of
 any integer type.
+
+!corrigendum 4.1.4(9/4)
+
+@drepl
+An @fa<attribute_reference> denotes a value, an object,
+a subprogram, or some other kind of program entity. For an
+@fa<attribute_reference> that denotes a value or an object,
+if its type is scalar, then its nominal subtype is the base subtype of
+the type; if its type is tagged, its nominal subtype is the first subtype of
+the type; otherwise, its nominal subtype is a subtype of the type
+without any constraint or @fa<null_exclusion>. Similarly, unless explicitly
+specified otherwise, for an @fa<attribute_reference> that denotes a function,
+when its result type is scalar, its result subtype is the base subtype of
+the type, when its result type is tagged, the result subtype is the first
+subtype of the type, and when the result type is some other type,
+the result subtype is a subtype of the type without any constraint or
+@fa<null_exclusion>.
+@dby
+An @fa<attribute_reference> denotes a value, an object, a subprogram, or some
+other kind of program entity. Unless explicitly specified otherwise,
+for an @fa<attribute_reference> that denotes a value or an object,
+if its type is scalar, then its nominal subtype is the base subtype of
+the type; if its type is tagged, its nominal subtype is the first subtype of
+the type; otherwise, its nominal subtype is a subtype of the type without any
+constraint, @fa<null_exclusion>, or predicate. Similarly, unless explicitly
+specified otherwise, for an @fa<attribute_reference> that denotes a function,
+when its result type is scalar, its result subtype is the base subtype of
+the type, when its result type is tagged, the result subtype is the first
+subtype of the type, and when the result type is some other type,
+the result subtype is a subtype of the type without any constraint,
+@fa<null_exclusion>, or predicate.
+
+!corrigendum 6.1.1(7/3)
+
+@drepl
+Within the expression for a Pre'Class or Post'Class aspect for a primitive
+subprogram of a tagged type @i<T>, a name that denotes a formal parameter of
+type @i<T> is interpreted as having type @i<T>'Class. Similarly, a name that
+denotes a formal access parameter of type access-to-@i<T> is interpreted as
+having type access-to-@i<T>'Class. This ensures that the expression is
+well-defined for a primitive subprogram of a type descended from @i<T>.
+@dby
+Within the expression for a Pre'Class or Post'Class aspect for a primitive
+subprogram @i<S> of a tagged type @i<T>, a @fa<name> that denotes a formal
+parameter (or @i<S>'Result) of type @i<T> is interpreted as though it
+had a (notional) type @i<NT> that is a formal derived type whose ancestor type
+is @i<T>, with directly visible primitive operations. Similarly, a @fa<name>
+that denotes a formal access parameter (or @i<S>'Result) of type access-to-@i<T>
+is interpreted as having type access-to-@i<NT>. The result of this
+interpretation is that the only operations that can be applied to such
+@fa<name>s are those defined for such a formal derived type.
+
+!corrigendum 6.1.1(26/3)
+
+@drepl
+@xhang<@xterm<X'Old>
+For each X'Old in a postcondition expression that is enabled, a constant
+is implicitly declared at the beginning of the subprogram or entry. The
+constant is of the type of X and is initialized to the result of evaluating
+X (as an expression) at the point of the constant declaration. The value of
+X'Old in the postcondition expression is the value of this constant; the
+type of X'Old is the type of X. These implicit constant declarations
+occur in an arbitrary order.>
+@dby
+@xhang<@xterm<X'Old>
+Each X'Old in a postcondition expression that is enabled denotes
+a constant that is implicitly declared at the beginning of the
+subprogram body, entry body, or accept statement.>
+
+@xindent<The implicitly declared entity denoted by each occurrence of X'Old
+is declared as follows:>
+
+@xinbull<If X is of an anonymous access type defined by an
+@fa<access_definition> @i<A> then@hr
+@fc<   @i<X'Old> : @b<constant> @i<A> := X;>>
+
+@xinbull<If X is of a specific tagged type @i<T> then@hr
+@fc<   @i<@ft<anonymous>> : @b<constant> @i<T>'Class := @i<T>'Class (X);@hr
+   @i<X'Old> : @i<T> @b<renames> @i<T>(@i<@ft<anonymous>>);>@hr
+   where the name X'Old denotes the object renaming.>
+
+@xinbull<Otherwise@hr
+@fc<   @i<X'Old> : @b<constant> @i<S> := X;>@hr
+   where @i<S> is the nominal subtype of X. This includes
+the case where the type of @i<S> is an anonymous array type or a
+universal type.>
+
+@xindent<The nominal subtype of X'Old is as implied by the above definitions. The
+expected type of the prefix of an Old attribute is that of the attribute.
+Similarly, if an Old attribute shall resolve to be of some type, then
+the prefix of the attribute shall resolve to be of that type.>
+
+!corrigendum 6.1.1(37/3)
+
+@drepl
+For any subprogram or entry call (including dispatching calls), the checks
+that are performed to verify specific precondition expressions and specific
+and class-wide postcondition expressions are determined by those for the subprogram
+or entry actually invoked. Note that the class-wide postcondition expressions
+verified by the postcondition check that is part of a call on a primitive subprogram
+of type @i<T> includes all class-wide postcondition expressions originating
+in any progenitor of @i<T>, even if the primitive subprogram called
+is inherited from a type @i<T1> and some of the postcondition expressions do
+not apply to the corresponding primitive subprogram of @i<T1>.
+@dby
+For any call to a subprogram or entry @i<S> (including dispatching calls), the
+checks that are performed to verify specific precondition expressions and
+specific and class-wide postcondition expressions are determined by those for
+the subprogram or entry actually invoked. Note that the class-wide postcondition
+expressions verified by the postcondition check that is part of a call on a
+primitive subprogram of type @i<T> includes all class-wide postcondition
+expressions originating in any progenitor of @i<T>, even if the primitive
+subprogram called is inherited from a type @i<T1> and some of the postcondition
+expressions do not apply to the corresponding primitive subprogram of @i<T1>.
+Any operations within a class-wide postcondition expression that were resolved
+as primitive operations of the (notional) formal derived type @i<NT>, are in
+the evaluation of the postcondition bound to the corresponding operations of
+the type identified by the controlling tag of the call on @i<S>. This applies
+to both dispatching and non-dispatching calls on @i<S>.
+
+!corrigendum 6.1.1(38/3)
+
+@drepl
+The class-wide precondition check for a call to a subprogram or entry consists
+solely of checking the class-wide precondition expressions that apply to the denoted
+callable entity (not necessarily the one that is invoked).
+@dby
+The class-wide precondition check for a call to a subprogram or entry @i<S>
+consists solely of checking the class-wide precondition expressions that apply
+to the denoted callable entity (not necessarily to the one that is invoked).
+Any operations within such an expression that were resolved as primitive
+operations of the (notional) formal derived type @i<NT> are in the evaluation
+of the precondition bound to the corresponding operations of the type
+identified by the controlling tag of the call on @i<S>. This applies to both
+dispatching and non-dispatching calls on @i<S>.
+
+!corrigendum 6.3.1(12)
+
+@drepl
+@xbullet<The default calling convention is @i<protected> for a protected
+subprogram, and for an access-to-subprogram type with the reserved word
+@b<protected> in its definition.>
+@dby
+@xbullet<The default calling convention is @i<protected> for a protected
+subprogram, for a prefixed view of a subprogram with a synchronization kind of
+By_Protected_Procedure, and for an access-to-subprogram type with the
+reserved word @b<protected> in its definition.>
+
+!corrigendum 6.3.1(13)
+
+@drepl
+@xbullet<The default calling convention is @i<entry> for an entry.>
+@dby
+@xbullet<The default calling convention is @i<entry> for an entry and for a
+prefixed view of a subprogram with a synchronization kind of By_Entry.>
+
+!comment 6.4.1(6.26-9/4) moves to 6.4.1(5) - This change is
+!comment made in the !corrigendum of the original AI (AI12-0074-1).
+
+!corrigendum 6.4.1(13.1/3)
+
+@drepl
+@xinbull<For a scalar type that has the Default_Value aspect specified, the
+formal parameter is initialized from the value of the actual, without checking
+that the value satisfies any constraint or any predicate;>
+@dby
+@xinbull<For a scalar type that has the Default_Value aspect specified,
+the formal parameter is initialized from the value of the actual,
+without checking that the value satisfies any constraint or any
+predicate. Furthermore, if the actual parameter
+is a view conversion and either>
+@xi2bull<there exists no type (other than a root numeric type) that
+is an ancestor of both the target type and the type of the
+operand of the conversion; or>
+@xi2bull<the Default_Value aspect is unspecified for the type of the
+operand of the conversion>
+@xindent<then Program_Error is raised;>
+
+!corrigendum 7.3.2(5/3)
+
+@drepl
+Within an invariant expression, the identifier of
+the first subtype of the associated type denotes the current instance
+of the type. Within an invariant expression associated with type @i<T>,
+the type of the current instance is @i<T> for the Type_Invariant aspect and
+@i<T>'Class for the Type_Invariant'Class aspect.
+@dby
+Within an invariant expression, the identifier of
+the first subtype of the associated type denotes the current instance
+of the type. Within an invariant expression for the Type_Invariant aspect
+of a type @i<T>, the type of this current instance is @i<T>. Within
+an invariant expression for the Type_Invariant'Class aspect of a type
+@i<T>, the type of this current instance is interpreted as though it
+had a (notional) type @i<NT> that is a visible formal derived type whose
+ancestor type is @i<T>. The effect of this interpretation is that the
+only operations that can be applied to this current instance are those defined
+for such a formal derived type.
+
+!corrigendum 7.3.2(21/3)
+
+@drepl
+If performing checks is required by the Invariant or Invariant'Class assertion
+policies (see 11.4.2) in effect at the point of corresponding aspect
+specification applicable to a given type, then the respective invariant
+expression is considered @i<enabled>.
+@dby
+If performing checks is required by the Type_Invariant or Type_Invariant'Class
+assertion policies (see 11.4.2) in effect at the point of the corresponding aspect
+specification applicable to a given type, then the respective invariant
+expression is considered @i<enabled>.
+
+!corrigendum 7.3.2(22/3)
+
+@dinsa
+The invariant check consists of the evaluation of each enabled invariant
+expression that applies to @i<T>, on each of the objects specified above.
+If any of these evaluate to False, Assertions.Assertion_Error is
+raised at the point of the object initialization, conversion, or call.
+If a given call requires more than one evaluation of an invariant
+expression, either for multiple objects of a single type or for
+multiple types with invariants, the evaluations are performed in an
+arbitrary order, and if one of them evaluates to False, it is not specified
+whether the others are evaluated. Any invariant check is performed
+prior to copying back any by-copy @b<in out> or @b<out> parameters.
+Invariant checks, any postcondition check, and any constraint or predicate checks
+associated with @b<in out> or @b<out> parameters are performed in an arbitrary order.
+@dinst
+For an invariant check on a value of type @i<T1> based on a class-wide invariant
+expression inherited from an ancestor type @i<T>, any operations within the
+invariant expression that were resolved as primitive operations of the
+(notional) formal derived type @i<NT> are bound to the corresponding operations
+of type @i<T1> in the evaluation of the invariant expression for the check
+on @i<T1>.
+
+!corrigendum 11.3(3)
+
+@drepl
+The @fa<name>, if any, in a @fa<raise_statement> shall denote an exception. A 
+@fa<raise_statement> with no @i<exception_>@fa<name> (that is, a @i<re-raise
+statement>) shall be within a handler, but not within a body enclosed by that
+handler. 
+@dby
+The @i<exception_>@fa<name>, if any, of a @fa<raise_statement> or
+@fa<raise_expression> shall denote an exception. A @fa<raise_statement> with
+no @i<exception_>@fa<name> (that is, a @i<re-raise statement>)
+shall be within a handler, but not within a body enclosed by that handler.
+
+!corrigendum 11.3(3.1/2)
+
+@drepl
+The @fa<expression>, if any, in a @fa<raise_statement>, is expected
+to be of type String.
+@dby
+A @i<string_>@fa<expression> of a @fa<raise_statement> or @fa<raise_expression> is expected
+to be of type String.
+
+The expected type for a @fa<raise_expression> shall be any single type.
+
+!corrigendum 11.3(4/2)
+
+@drepl
+To @i<raise an exception> is to raise a new occurrence of that exception, as
+explained in 11.4. For the execution of a @fa<raise_statement> with an
+@i<exception_>@fa<name>, the named exception is raised. If a
+@i<string_>@fa<expression> is present, the @fa<expression> is evaluated and its
+value is associated with the exception occurrence. For the execution of a
+re-raise statement, the exception occurrence that caused transfer of control to
+the innermost enclosing handler is raised again.
+@dby
+To @i<raise an exception> is to raise a new occurrence of that exception, as
+explained in 11.4. For the execution of a @fa<raise_statement> with an
+@i<exception_>@fa<name>, the named exception is raised. Similarly, for the evaluation
+of a @fa<raise_expression>, the named exception is raised. In both of these cases,
+if a @i<string_>@fa<expression> or @i<string_>@fa<simple_expression> is present,
+the expression is evaluated and its value is associated with the exception
+occurrence. For the execution of a re-raise statement, the exception occurrence
+that caused transfer of control to the innermost enclosing handler is raised again.
+
+@xindent<@s9<NOTES@hr
+1  If the evaluation of a @i<string_>@fa<expression> or
+@i<string_>@fa<simple_expression> raises an exception, that
+exception is propagated instead of the one denoted by the @i<exception_>@fa<name>
+of the @fa<raise_statement> or @fa<raise_expression>.>>
+
+!corrigendum A(3)
+
+@drepl
+The implementation shall ensure that each language-defined subprogram is
+reentrant in the sense that concurrent calls on the same subprogram perform as
+specified, so long as all parameters that could be passed by reference denote
+nonoverlapping objects.
+@dby
+The implementation shall ensure that each language-defined subprogram
+is reentrant in the sense that concurrent calls on any language-defined
+subprogram perform as specified, so long as all objects that are denoted by
+parameters that could be passed by reference or designated by parameters of
+an access type are nonoverlapping.
+
+For the purpose of determining whether concurrent calls on text input-output
+subprograms are required to perform as specified above, when calling a
+subprogram within Text_IO or its children that implicitly operates on one of the
+default input-output files, the subprogram is considered to have a
+parameter of Current_Input or Current_Output (as appropriate).
+
+!corrigendum A.18.10(2/3)
+
+@drepl
+A multiway tree container object manages a tree of internal @i<nodes>, each of which
+contains an element and pointers to the parent, first child, last child, next
+(successor) sibling, and previous (predecessor) sibling internal nodes. A cursor
+designates a particular node within a tree (and by extension the element
+contained in that node, if any). A cursor keeps designating the same node (and element)
+as long as the node is part of the container, even if the node is moved within the
+container.
+@dby
+A multiway tree container object manages a tree of @i<nodes>, consisting of a
+@i<root node> and a set of @i<internal nodes>; each internal node
+contains an element and pointers to the parent, first child, last child, next
+(successor) sibling, and previous (predecessor) sibling internal nodes. A cursor
+designates a particular node within a tree (and by extension the element
+contained in that node, if any). A cursor keeps designating the same node (and element)
+as long as the node is part of the container, even if the node is moved within the
+container.
+
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent