CVS difference for ai05s/ai05-0142-4.txt

Differences between 1.10 and version 1.11
Log of other versions for file ai05s/ai05-0142-4.txt

--- ai05s/ai05-0142-4.txt	2010/08/13 05:32:36	1.10
+++ ai05s/ai05-0142-4.txt	2010/08/21 02:54:00	1.11
@@ -1,8 +1,8 @@
-!standard 3.10(9/2)                                  10-06-11  AI05-0142-4/07
+!standard 3.10(9/2)                                  10-08-20  AI05-0142-4/08
 !standard 3.10.2(13.1/2)
 !standard 3.10.2(19/2)
 !standard 6.1(15/2)
-!standard 6.1(23)
+!standard 6.1(23/2)
 !standard 6.2(3)
 !standard 6.2(10)
 !standard 6.3.1(16/2)
@@ -11,6 +11,7 @@
 !standard 7.6.1(13/3)
 !standard C.6(12)
 !class Amendment 09-05-17
+!status Amendment 2012 10-08-20
 !status ARG Approved  7-0-3  10-06-19
 !status work item 09-05-17
 !status received 09-05-17
@@ -458,9 +459,211 @@
 See AI05-0212-1 for how this feature is defined and used in the Containers libraries,
 including examples of use.
 
+!corrigendum 3.10(9/2)
+
+@drepl
+A view of an object is defined to be @i<aliased> if it is defined by an
+@fa<object_declaration> or @fa<component_definition> with the reserved word
+@b<aliased>, or by a renaming of an aliased view. In addition, the dereference
+of an access-to-object value denotes an aliased view, as does a view conversion
+(see 4.6) of an aliased view. The current instance of a limited tagged type, a
+protected type, a task type, or a type that has the reserved word @b<limited>
+in its full definition is also defined to be aliased. Finally, a formal
+parameter or generic formal object of a tagged type is defined to be aliased.
+Aliased views are the ones that can be designated by an access value.
+@dby
+A view of an object is defined to be @i<aliased> if it is defined by an
+@fa<object_declaration>, @fa<parameter_specification>, or @fa<component_definition>
+with the reserved word
+@b<aliased>, or by a renaming of an aliased view. In addition, the dereference
+of an access-to-object value denotes an aliased view, as does a view conversion
+(see 4.6) of an aliased view. The current instance of a limited tagged type, a
+protected type, a task type, or a type that has the reserved word @b<limited>
+in its full definition is also defined to be aliased. Finally, a formal
+parameter or generic formal object of a tagged type is defined to be aliased.
+Aliased views are the ones that can be designated by an access value.
+
+
+!corrigendum 3.10.2(13.1/2)
+
+@dinsa
+@xbullet<The accessibility level of the anonymous access type of an access
+parameter specifying an access-to-subprogram type is deeper than that of
+any master; all such anonymous access types have this same level.>
+@dinst
+@xbullet<The accessibility level of an explicitly aliased (see 6.1) formal
+parameter in a function body is determined by the point of call (which is the
+same level that the return object ultimately will have).>
+
+
+!comment the following REPLACES the change in AI05-0051-1, not yet finished.
+!corrigendum 3.10.2(19/2)
+
+@dinsa
+@xbullet<The statically deeper relationship does not apply to the accessibility
+level of the anonymous type of an access parameter specifying an
+access-to-object type; that is, such an accessibility level is not
+considered to be statically deeper, nor statically shallower, than
+any other.>
+@dinst
+@xbullet<Inside a return statement that applies to a function @i<F>, when
+determining whether the accessibility level of an explicitly
+aliased parameter of @i<F> is statically deeper than the level of the
+return object of @i<F>, the level of the return object is presumed to
+be the same as that of the level of the explicitly aliased
+parameter; for statically comparing with the level of other
+entities, the level of the return object of @i<F> is
+presumed to be the same as that of the master that elaborated
+the function body of @i<F>.>
+
+
+!corrigendum 6.1(15/2)
+
+@drepl
+@xcode<@fa<parameter_specification ::=
+    defining_identifier_list : mode [null_exclusion] subtype_mark [:= default_expression]
+  | defining_identifier_list : access_definition [:= default_expression]>>
+@dby
+@xcode<@fa<parameter_specification ::=
+    defining_identifier_list : [>@ft<@b<aliased>>@fa<] mode [null_exclusion] subtype_mark [:= default_expression]
+  | defining_identifier_list : access_definition [:= default_expression]>>
+
+
+!corrigendum 6.1(23/2)
+
+@dinsa
+The nominal subtype of a formal parameter is the subtype denoted
+by the @fa<subtype_mark>, or
+defined by the @fa<access_definition>, in the @fa<parameter_specification>.
+The nominal subtype of a function result is the subtype
+denoted by the @fa<subtype_mark>, or
+defined by the @fa<access_definition>, in the @fa<parameter_and_result_profile>.
+@dinst
+An @i<explicitly aliased parameter> is a formal parameter whose @fa<parameter_specification>
+includes the reserved word @b<aliased>.
+
+!corrigendum 6.2(3)
+
+@drepl
+A type is a @i<by-copy> type if it is an elementary type, or if it is a descendant of a private
+type whose full type is a by-copy type. A parameter of a by-copy type is passed by copy.
+
+@dby
+A type is a @i<by-copy> type if it is an elementary type, or if it is a descendant of a private
+type whose full type is a by-copy type. A parameter of a by-copy type
+that is not explicitly aliased is passed by copy.
+
+!corrigendum 6.2(10)
+
+@drepl
+A parameter of a by-reference type is passed by reference. Each value of a
+by-reference type has an associated object. For a parenthesized expression,
+@fa<qualified_expression>, or @fa<type_conversion>, this object is the one associated
+with the operand.
+@dby
+A parameter of a by-reference type is passed by reference{, as is an explicitly
+aliased parameter of any type}. Each value of a by-reference type has an associated
+object. For a parenthesized expression, @fa<qualified_expression>,
+or @fa<type_conversion>, this object is the one associated with the
+operand.
+
+!corrigendum 6.3.1(16/2)
+
+@drepl
+Two profiles are @i<mode conformant> if they are type-conformant, and
+corresponding parameters have identical modes, and, for access parameters or
+access result types, the designated subtypes statically match, or the
+designated profiles are subtype conformant.
+@dby
+Two profiles are @i<mode conformant> if they are type conformant,
+corresponding parameters have identical modes, both or neither are explicitly
+aliased parameters, and, for access parameters or access result types, the
+designated subtypes statically match, or the designated profiles are subtype
+conformant.
+
+
+!corrigendum 6.4.1(6)
+
+@dinsa
+The type of the actual parameter associated with an access parameter
+shall be convertible (see 4.6) to its anonymous access type.
+@dinst
+If the formal parameter is an explicitly aliased parameter, the type of the actual
+parameter shall be tagged or the actual parameter shall be an aliased view of
+an object. Further, if the formal parameter subtype @i<F> is untagged:
+@xbullet<the subtype @i<F> shall statically match the nominal subtype of the actual
+object; or>
+@xbullet<the subtype @i<F> shall be unconstrained, discriminated in its full view,
+and unconstrained in any partial view.>
+
+In a function call, the accessibility level of the actual object
+for each explicitly aliased parameter shall not be statically deeper than
+accessibility level of the master of the function result.
+
+!corrigendum 6.4.1(15)
+
+@dinsa
+@xinbull<For any other type, the formal parameter is uninitialized. If composite,
+a view conversion of the actual parameter to the nominal subtype of the formal is
+evaluated [(which might raise Constraint_Error)], and the actual subtype of the
+formal is that of the view conversion. If elementary, the actual subtype of the
+formal is given by its nominal subtype.>
+@dinst
+@xbullet<In a function call, for each explicitly aliased parameter, a
+check is made that the accessibility level of the master of the actual object is
+not deeper than that of the master of the function result.>
+
+
+!corrigendum 7.6.1(13/2)
+
+@drepl
+The master of an object is the master enclosing its creation whose
+accessibility level (see 3.10.2) is equal to that of the object.
+@dby
+The master of an object is the master enclosing its creation whose
+accessibility level (see 3.10.2) is equal to that of the object,
+except in the case of an anonymous object representing the result of
+an @fa<aggregate> or function call. If such an anonymous object
+is part of the actual parameter expression for an explicitly aliased
+parameter of a function call, the master of the object is the innermost
+master enclosing the evaluation of the @fa<aggregate> or function call, excluding
+the @fa<aggregate> or function call itself. Otherwise, the master of such
+an anonymous object is the innermost master enclosing the evaluation of the
+@fa<aggregate> or function call, which may be the @fa<aggregate> or function
+call itself.
+
+
+!corrigendum C.6(12)
+
+@drepl
+If an atomic object is passed as a parameter, then the type of the formal
+parameter shall either be atomic or allow pass by copy (that
+is, not be a nonatomic by-reference type). If an atomic object is used
+as an actual for a generic formal object of mode @b<in out>, then the
+type of the generic formal object shall be atomic. If the @fa<prefix> of
+an @fa<attribute_reference> for an Access attribute denotes an atomic
+object (including a component), then the designated type of
+the resulting access type shall be atomic. If an atomic type is used as
+an actual for a generic formal derived type, then the ancestor of the
+formal type shall be atomic or allow pass by copy. Corresponding rules
+apply to volatile objects and types.
+@dby
+If an atomic object is passed as a parameter, then the formal
+parameter shall either have an atomic type or allow pass by copy. If an
+atomic object is used
+as an actual for a generic formal object of mode @b<in out>, then the
+type of the generic formal object shall be atomic. If the @fa<prefix> of
+an @fa<attribute_reference> for an Access attribute denotes an atomic
+object (including a component), then the designated type of
+the resulting access type shall be atomic. If an atomic type is used as
+an actual for a generic formal derived type, then the ancestor of the
+formal type shall be atomic or allow pass by copy. Corresponding rules
+apply to volatile objects and types.
+
+
 !ACATS test
 
-ACATS tests would be needed for this feature.
+ACATS tests will be needed for this feature.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent