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

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

--- ai12s/ai12-0378-1.txt	2020/07/03 01:39:51	1.6
+++ ai12s/ai12-0378-1.txt	2020/07/09 07:15:40	1.7
@@ -1,6 +1,7 @@
-!standard 6.4.1(13/3)                                  20-06-18  AI12-0378-1/04
+!standard 6.4.1(13/3)                                  20-07-07  AI12-0378-1/05
 !standard 6.4.1(18/3)
 !class Binding Interpretation 20-06-18
+!status Amendment 1-2012 20-07-07
 !status work item 20-04-29
 !status received 20-03-26
 !priority Low
@@ -59,7 +60,7 @@
     or exclusion of the null value that might apply to the formal
     type.
 
-       AARM Implementation Note: This rule means that any tag checks,
+       AARM Implementation Note: This rule means that any tag checks
        and accessibility checks can be assumed to pass for an out
        parameter, but constraints, null exclusions, and predicates cannot
        be assumed unless the compiler can prove that the object has been
@@ -83,17 +84,19 @@
   types is well-defined in the case of a view conversion. Null will be passed in
   for conversions that may have problematic accessibility or tags. If the
   accessibility or tag check(s) would have passed, and the out parameter is
-  read before it is written, Constraint_Error may be raised by Ada 202x when
-  it would not have been in Ada 2012. Additionally, if the called subprogram
-  does not write the out parameter at all, the actual object will be
-  overwritten with null (and possibly raise Constraint_Error if the object is
-  null excluding), while the object would be unchanged in Ada 2012. Such cases
-  are thought to be rare, as most out parameters of access types are
-  overwritten before being read. In addition, at least one commonly used
-  Ada compiler already does passes null in these cases.
+  read before it is written (perhaps to read a bound or discriminant), 
+  Constraint_Error may be raised by Ada 202x when it would not have been in 
+  Ada 2012. Additionally, if the called subprogram does not write the out 
+  parameter at all, the actual object will be overwritten with null (and 
+  possibly raise Constraint_Error if the object is null excluding), while the
+  object would be unchanged in Ada 2012. Such cases are thought to be rare, as
+  most out parameters of access types are overwritten before being read. In 
+  addition, at least one widely-used Ada compiler already passes null 
+  in these cases.
 
 Modify AARM 6.4.1(18.j/4): [to remove any mention of access types - there is
-no longer any compile-time incompatibility]
+no longer any compile-time incompatibility; this also updates the text for
+AI12-0377-1]
 
   Corrigendum: Added rules to ensure that the value passed into a{n} out
   parameter for {scalar}[elementary] types is well-defined in the case of
@@ -211,6 +214,56 @@
 permission or suggestion related to normal conversions or IN OUT
 parameters in such a case. We presume implementations will do the
 (implementation-defined) "right thing" in such cases.
+
+!corrigendum 6.4.1(13/3)
+
+@drepl
+@xinbull<For an access type, the formal parameter is initialized from the
+value of the actual, without checking that the value satisfies any 
+constraint, any predicate, or any exclusion of the null value;>
+@dby
+@xinbull<For an access type:>
+
+@xi2bull<if the designated type of the actual is a class-wide type @i<T>'Class
+  and the designated type of the formal is neither an ancestor of @i<T>,
+  nor a class-wide type that covers @i<T>, then the formal parameter
+  is initialized to the null value of the formal type;>
+
+@xi2bull<if the actual is a stand-alone object of an anonymous access type,
+  and the accessibility level of the formal type is not library
+  level, then the formal parameter is initialized to the null value
+  of the formal type;>
+
+@xi2bull<if the call is within the body of an instance of a generic unit,
+  the actual or the formal type is descended from a generic formal
+  access type of the generic unit, and the actual and formal types
+  neither share an ancestor nor is the formal type accessibility at
+  library level, then the formal parameter is initialized to the null
+  value of the formal type;>
+
+@xi2bull<otherwise, the formal parameter is initialized to the value of the
+  actual parameter, without checking that the value satisfies any
+  constraint.>
+
+@xindent<In all of the above cases, no check is performed for any predicate
+or exclusion of the null value that might apply to the formal type.>
+
+!corrigendum 6.4.1(18/3)
+
+@dinsa
+If the nominal subtype of a formal parameter with discriminants is constrained 
+or indefinite, and the parameter is passed by reference, then the execution of 
+the call is erroneous if the value of any discriminant of the actual is 
+changed while the formal parameter exists (that is, before leaving the 
+corresponding callable construct). 
+@dinst
+@s8<@i<Implementation Permissions>>
+
+For an @b<out> parameter of an access type, if the representation of the
+actual type and the formal type differ, and there are values of the
+actual type that cannot be represented as values of the formal type,
+the implementation may initialize the formal parameter with the null
+value of the formal type.
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent