CVS difference for ai05s/ai05-0107-1.txt

Differences between 1.4 and version 1.5
Log of other versions for file ai05s/ai05-0107-1.txt

--- ai05s/ai05-0107-1.txt	2009/05/24 03:42:49	1.4
+++ ai05s/ai05-0107-1.txt	2009/07/11 03:06:22	1.5
@@ -1,8 +1,10 @@
-!standard 7.6.1(20)                                            09-05-23  AI05-0107-1/02
+!standard 7.6.1(20)                                            09-06-27  AI05-0107-1/03
 !standard 13.11(16)
 !standard 13.11(21)
 !standard 13.11.2(9/2)
 !class binding interpretation 08-08-07
+!status Amendment 201Z 09-06-27
+!status ARG Approved  7-0-0  09-06-14
 !status work item 08-08-07
 !status received 06-06-21
 !priority Medium
@@ -67,24 +69,12 @@
 pool is a user-defined object, then the storage is allocated by calling Allocate
 as described below.
 
-[Editor's note: The rules about calls need to apply to more than just allocators,
-so I split them out. These rules are requirements on the implementation (as opposed
-to a description as to how the calls operate).
-
-The minutes of the Tallahassee meeting has suggested moving paragraphs 16-20
-under Dynamic Semantics. I didn't do that because (1) we later decided
-to move most of the new text to be Implementation Requirements, meaning this is
-not a necessary change anymore; (2) paragraphs 17-19 define the storage pool of a
-type, which can be construed to be a Static Semantics definition; (3) Actually doing
-this in our document tools would require deleting and reinserting these paragraphs,
-which is messy and would seem to imply more change than actually has occurred.]
-
 Add after 13.11(21):
 
 Implementation Requirements
 
-The Allocate procedure of a user-defined storage pool object P may only be
-called by the implementation to allocate storage for a type T whose pool is P and:
+The Allocate procedure of a user-defined storage pool object P may be called by
+the implementation only to allocate storage for a type T whose pool is P and:
 
 * During the execution of an allocator of type T;
 
@@ -122,10 +112,14 @@
 the alignment of the specific type identified by the tag of the object being
 created. The result returned in the Storage_Address parameter is used as the
 address of the allocated storage, which is a contiguous block of memory of
-Size_In_Storage_Elements storage elements. Any exception propagated by Allocate
-is propagated by the construct that contained the call. 
+Size_In_Storage_Elements storage elements. Redundant: [Any exception propagated
+by Allocate is propagated by the construct that contained the call.] 
+
+[Editor's Note: The above paragraph contains the changes made by AI05-0116-1. The
+following AARM note is moved from 13.11(16.b).]
 
-[Editor's Note: The above paragraph contains the changes made by AI05-0116-1.]
+AARM Ramification: Note that the implementation does not turn other exceptions
+into Storage_Error.
 
 The number of calls to Allocate needed to implement an allocator for any
 particular type is unspecified. The number of calls to Deallocate
@@ -136,15 +130,15 @@
 AARM Reason: This supports objects that are allocated in one or more parts. The
 second sentence prevents extra or missing calls to Deallocate.
 
-The Deallocate procedure of a user-defined storage pool object P may only be
-called by the implementation to deallocate storage for a type T whose pool is P and
-either at the places when an Allocate call is allowed for P or
-during the execution of an instance of Unchecked_Deallocation for T.
-For such a call of Deallocate, P (T'Storage_Pool) is passed as the Pool parameter.
-The value of the Storage_Address parameter for a call to Deallocate is the
-value returned in the Storage_Address parameter of the corresponding Allocate
-call. The values of the Size_In_Storage_Elements and Alignment parameters are the
-same values passed to the corresponding Allocate call.
+The Deallocate procedure of a user-defined storage pool object P may be called
+by the implementation to deallocate storage for a type T whose pool is P only at
+the places when an Allocate call is allowed for P, during the execution of an
+instance of Unchecked_Deallocation for T, or as part of the finalization of the
+collection of T. For such a call of Deallocate, P (T'Storage_Pool) is passed as
+the Pool parameter. The value of the Storage_Address parameter for a call to
+Deallocate is the value returned in the Storage_Address parameter of the
+corresponding successful call to Allocate. The values of the Size_In_Storage_Elements and
+Alignment parameters are the same values passed to the corresponding Allocate call.
 Any exception propagated by Deallocate is propagated by the construct that
 contained the call. 
 
@@ -170,7 +164,7 @@
      Storage_Address is the value returned in the Storage_Address parameter
      of the corresponding Allocate call. Size_In_Storage_Elements and
      Alignment are the same values passed to the corresponding Allocate
-     call.] There is one exception: if the object being freed contains
+     call]. There is one exception: if the object being freed contains
      tasks, the object might not be deallocated. 
 
 [Editor's note: the deleted rules were moved to 13.11, as they apply to
@@ -190,9 +184,19 @@
 to be called implicitly as specifically as possible. We could have used more
 more general wording, possibly going as far as allowing it to be called at
 any time. But that seems bad; we don't want programmers to have to worry about
-Allocate being called in unusual places or by random tasks. Still, we could
-simplify the wording somewhat at the cost of more unusual cases potentially
-being allowed. The right trade-off is not completely clear.
+Allocate being called in unusual places or by random tasks.
+
+---
+
+We've reorganized the wording so that all of the description of what is passed
+to Allocate and Deallocate are Implementation Requirements. These are requirements
+on the implementation (as opposed to a description of how the routines operate),
+so this is the appropriate heading.
+
+Additionally, these requirements apply to all implementation-generated calls
+on Allocate and Deallocate, not just those directly associated with allocators
+and Unchecked_Deallocation. So it makes the most sense to give those as separate
+requirements, not tied to particular syntax.
 
 ---
 
@@ -298,10 +302,114 @@
 As such, the rules have been written to make it clear that this implementation is
 allowed.
 
-   
+!corrigendum 7.6.1(20)
 
---!corrigendum 13.11(21)
+@dinsa
+@xbullet<For a Finalize invoked by a transfer of control due to an abort or selection
+of a terminate alternative, the exception is ignored; any other finalizations due to
+be performed are performed.>   
+@dinst
+@s8<@i<Implementation Permissions>>
 
+If the execution of an @fa<allocator> propagates an exception, any parts of the
+allocated object that were successfully initialized may be finalized as
+part of the finalization of the innermost master enclosing the @fa<allocator>.
+
+!corrigendum 13.11(16)
+
+@drepl
+An @fa<allocator> of type T allocates storage from T's storage pool. If the storage pool
+is a user-defined object, then the storage is allocated by calling Allocate, passing
+T'Storage_Pool as the Pool parameter. The Size_In_Storage_Elements parameter indicates
+the number of storage elements to be allocated, and is no more than D'Max_Size_In_Storage_Elements,
+where D is the designated subtype. The Alignment parameter is D'Alignment. The result returned
+in the Storage_Address parameter is used by the @fa<allocator> as the address of the
+allocated storage, which is a contiguous block of memory of Size_In_Storage_Elements storage
+elements. Any exception propagated by Allocate is propagated by the @fa<allocator>. 
+@dby
+An @fa<allocator> of type @i<T> allocates storage from @i<T>'s storage pool. If the storage
+pool is a user-defined object, then the storage is allocated by calling Allocate
+as described below.
+
+!corrigendum 13.11(21)
+
+@dinsa
+If Storage_Pool is specified for an access type, then if Allocate can satisfy the request,
+it should allocate a contiguous block of memory, and return the address of the first storage
+element in Storage_Address. The block should contain Size_In_Storage_Elements storage elements,
+and should be aligned according to Alignment. The allocated storage should not be used for
+any other purpose while the pool element remains in existence. If the request cannot be
+satisfied, then Allocate should propagate an exception [(such as Storage_Error)]. If Allocate
+behaves in any other manner, then the program execution is erroneous. 
+@dinss
+@s8<@i<Implementation Requirements>>
+
+The Allocate procedure of a user-defined storage pool object @i<P> may be called by
+the implementation only to allocate storage for a type @i<T> whose pool is @i<P> and:
+
+@xbullet<During the execution of an @fa<allocator> of type @i<T>;>
+
+@xbullet<During the execution of a return statement for a function whose result is
+built-in-place in the result of an @fa<allocator> of type @i<T>;>
+
+@xbullet<During the execution of an assignment operation with a target of an allocated
+object of type @i<T> with a part that has an unconstrained discriminated subtype with
+defaults.>
+
+For one of the calls of Allocate described above, @i<P> (@i<T>'Storage_Pool) is passed as
+the Pool parameter. The Size_In_Storage_Elements parameter indicates the number
+of storage elements to be allocated, and is no more than
+@i<D>'Max_Size_In_Storage_Elements, where @i<D> is the designated subtype of @i<T>.
+The Alignment parameter is @i<D>'Alignment if @i<D> is a specific type, and otherwise is
+the alignment of the specific type identified by the tag of the object being
+created. The result returned in the Storage_Address parameter is used as the
+address of the allocated storage, which is a contiguous block of memory of
+Size_In_Storage_Elements storage elements. Any exception propagated
+by Allocate is propagated by the construct that contained the call. 
+
+The number of calls to Allocate needed to implement an @fa<allocator> for any
+particular type is unspecified. The number of calls to Deallocate
+needed to implement an instance of Unchecked_Deallocation (see 13.11.2) for
+any particular object is the same as the number of Allocate calls for that
+object.
+
+The Deallocate procedure of a user-defined storage pool object @i<P> may be called
+by the implementation to deallocate storage for a type @i<T> whose pool is @i<P>
+only at the places when an Allocate call is allowed for @i<P>, during the execution
+of an instance of Unchecked_Deallocation for @i<T>, or as part of the finalization
+of the collection of @i<T>. For such a call of Deallocate, @i<P> (@i<T>'Storage_Pool)
+is passed as the Pool parameter. The value of the Storage_Address parameter for a
+call to Deallocate is the value returned in the Storage_Address parameter of the
+corresponding successful call to Allocate. The values of the Size_In_Storage_Elements and
+Alignment parameters are the same values passed to the corresponding Allocate call.
+Any exception propagated by Deallocate is propagated by the construct that
+contained the call. 
+
+!corrigendum 13.11.2(9/2)
+
+@drepl
+@xhang<@xterms<3.>Free(X), when X is not equal to null first performs finalization of
+the object designated by X (and any coextensions of the object  see
+3.10.2), as described in 7.6.1. It then deallocates the storage
+occupied by the object designated by X (and any coextensions). If
+the storage pool is a user-defined object, then the storage is
+deallocated by calling Deallocate, passing
+access_to_variable_subtype_name'Storage_Pool as the Pool parameter.
+Storage_Address is the value returned in the Storage_Address parameter
+of the corresponding Allocate call. Size_In_Storage_Elements and
+Alignment are the same values passed to the corresponding Allocate
+call. There is one exception: if the object being freed contains
+tasks, the object might not be deallocated.>
+@dby
+@xhang<@xterms<3.>Free(X), when X is not equal to null first performs finalization of
+the object designated by X (and any coextensions of the object  see
+3.10.2), as described in 7.6.1. It then deallocates the storage
+occupied by the object designated by X (and any coextensions). If
+the storage pool is a user-defined object, then the storage is
+deallocated by calling Deallocate as described in 13.11.
+There is one exception: if the object being freed contains
+tasks, the object might not be deallocated.>
+
 !ACATS Test
 
 Permissions are hard to usefully test, and the ACATS isn't supposed to be testing
@@ -331,4 +439,15 @@
 
 ****************************************************************
 
+From: Randy Brukardt
+Added: Saturday, May 23, 2009
+
+The minutes of the Tallahassee meeting suggested moving paragraphs 16-20
+under Dynamic Semantics. I didn't do that because (1) we later decided
+to move most of the new text to be Implementation Requirements, meaning this is
+not a necessary change anymore; (2) paragraphs 17-19 define the storage pool of a
+type, which can be construed to be a Static Semantics definition; (3) Actually doing
+this in our document tools would require deleting and reinserting these paragraphs,
+which is messy and would seem to imply more change than actually has occurred.
 
+****************************************************************

Questions? Ask the ACAA Technical Agent