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

Differences between 1.1 and version 1.2
Log of other versions for file ai12s/ai12-0410-1.txt

--- ai12s/ai12-0410-1.txt	2020/12/04 04:20:00	1.1
+++ ai12s/ai12-0410-1.txt	2020/12/04 07:59:30	1.2
@@ -1,6 +1,9 @@
-!standard 5.5.2(2/3)                                  20-12-03  AI12-0410-1/01
-!standard 5.5.2(5/4)
-!standard 5.5.2(7/3)
+!standard 9.5(55/5)                                  20-12-03  AI12-0410-1/01
+!standard 13.11(17.1/5)
+!standard H.4(23.2/5)
+!standard H.4(23.4/5)
+!standard H.7(4/5)
+!standard H.7(7/5)
 !class Amendment 20-12-03
 !status work item 20-12-03
 !status received 20-12-02
@@ -19,7 +22,7 @@
 There is no way currently to indicate in a generic whether or not an allocator 
 or unchecked deallocation is performed on a formal access type A, even though 
 such operations can have significant side effects on an object, namely the 
-object A'Storage_Pool, which is not an explicit formal parameter.  To better 
+object A'Storage_Pool, which is not an explicit formal parameter. To better 
 understand the possible side effects of a generic, it is important to 
 understand whether there are any uses of the operations of the associated 
 storage pool.
@@ -27,8 +30,8 @@
 A separate more general issue is whether operations on a user-defined storage 
 pool, or for that matter, on any object of a limited private type, are 
 automatically synchronized thanks to underlying use of a task, a protected 
-object, or one or more atomic variables.  We leave that to a separate AI on 
-that topic.  We will focus here on how effects on storage pools are to be 
+object, or one or more atomic variables. We leave that to a separate AI on 
+that topic. We will focus here on how effects on storage pools are to be 
 handled.
 
 !proposal
@@ -36,7 +39,7 @@
 If the "No_Hidden_Indirect_Globals" restriction is in place, then an allocator 
 or unchecked deallocation for a formal access type or an access type with a 
 user-defined storage pool is considered an update to its storage pool, and the 
-storage pool must be covered by the applicable global aspects.  In a separate 
+storage pool must be covered by the applicable global aspects. In a separate 
 AI, we will address the issue of whether the operations on a user-defined 
 storage pool can safely be performed concurrently in separate threads, that 
 is, whether the storage pool object is considered to be "synchronized."  For 
@@ -49,8 +52,8 @@
 private part or body of a package.
 
 For precision, a global_object_name may be an attribute reference to the 
-Storage_Pool attribute of an access type.  This would also be an Annex H 
-feature.  By specifying the storage pool object this way, you don't have to 
+Storage_Pool attribute of an access type. This would also be an Annex H 
+feature. By specifying the storage pool object this way, you don't have to 
 know whether or not the storage pool object of a formal access type is 
 synchronized when writing the Global aspect.
 
@@ -69,7 +72,7 @@
 
   The type(s) of the standard pool(s), and the primitive Allocate,
   Deallocate, and Storage_Size subprograms for the standard pool(s) are
-  nonblocking.  {Concurrent invocations of these subprograms do not
+  nonblocking. {Concurrent invocations of these subprograms do not
   conflict with one another (see 9.10) when applied to standard storage
   pools.}
   
@@ -126,14 +129,14 @@
 !discussion
 
 As explained in the !problem, side effects on storage pools can be
-significant.  This AI attempts to address this.  We only enforce checks
+significant. This AI attempts to address this. We only enforce checks
 on storage pools if the restriction No_Hidden_Indirect_Globals is
 present, since without that restriction the use of access types is not
 necessarily reflected at all within global aspects.
 
 Although it has generally been assumed, there was no specific statement
 that concurrent allocators were safe, and did not represent any sort
-of race condition.  In this AI we add such a statement, along with
+of race condition. In this AI we add such a statement, along with
 the statement that they are nonblocking.
 
 We leave to a separate AI the more general issue of whether concurrent
@@ -143,13 +146,13 @@
 
 For standard storage pools, we don't worry about deallocation or
 Storage_Size, as they are not presumed to have any interesting side
-effects.  We worry about allocation because if we were to write "Global
+effects. We worry about allocation because if we were to write "Global
 => null" for a function that returns the result of an allocator, it
 might imply that it returns the same result on each invocation, which is
-clearly not the case.  We don't worry about subprograms whose outputs
+clearly not the case. We don't worry about subprograms whose outputs
 don't include any parts that are visibly of an access type, to be
 consistent with the model that such "hidden" access types are presumed
-to be "well behaved".  Clearly such an assumption is not always true,
+to be "well behaved". Clearly such an assumption is not always true,
 but we choose to follow this assumption consistently for the purposes of
 the Global aspect. Presuming they are "well behaved" then one would
 expect, for example, an equality operator over two "compound" objects

Questions? Ask the ACAA Technical Agent