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

--- ai05s/ai05-0107-1.txt	2009/07/11 03:06:22	1.5
+++ ai05s/ai05-0107-1.txt	2009/10/15 04:20:17	1.6
@@ -1,4 +1,4 @@
-!standard 7.6.1(20)                                            09-06-27  AI05-0107-1/03
+!standard 7.6.1(20)                                            09-10-12  AI05-0107-1/04
 !standard 13.11(16)
 !standard 13.11(21)
 !standard 13.11.2(9/2)
@@ -104,9 +104,9 @@
 AARM Discussion: Of course, explicit calls to the procedure are also allowed and
 are not bound by any of the rules found here.
 
-For one of the calls of Allocate described above, P (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
+For one of the calls of Allocate described above, P (equivalent to 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
 D'Max_Size_In_Storage_Elements, where D is the designated subtype of T.
 The Alignment parameter is D'Alignment if D is a specific type, and otherwise is
 the alignment of the specific type identified by the tag of the object being
@@ -134,9 +134,9 @@
 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
+collection of T. For such a call of Deallocate, P (equivalent to 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
@@ -167,10 +167,10 @@
      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
-all calls to Deallocate, even ones that are generated by the compiler
-to prevent storage leaks and are not directly associated with a call
-of Unchecked_Deallocation.]
+[Editor's note: the deleted rules were moved to 13.11 as described above,
+as they apply to all calls to Deallocate, even ones that are generated by the
+compiler to prevent storage leaks and that are not directly associated with
+a call of Unchecked_Deallocation.]
 
 
 !discussion
@@ -182,7 +182,7 @@
 
 We have worded the list of places where Allocate and Deallocate are allowed
 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
+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.
 
@@ -226,8 +226,8 @@
 
 It has been said that there is no need to allow early finalization in order
 to prevent leaks. The reason given (by *usually* knowledgable people) is that
-object isn't "allocated" until the initialization finishes successfully. This
-reason doesn't hold water, however, as it fails to take into account
+the object isn't "allocated" until the initialization finishes successfully.
+This reason doesn't hold water, however, as it fails to take into account
 controlled components. A controlled component may finish its initialization
 but the whole object may not by a later exception during the initialization
 of some other component. The Ada model surely does not allow dropping this
@@ -262,7 +262,7 @@
 This particular permission is considered quite important by the author.
 
 The memory model of Janus/Ada assumes that Allocate and Deallocate can
-be called at any time that's convinient to the compiler. That was the model
+be called at any time that's convenient to the compiler. That was the model
 for the Janus/Ada 83 compiler, and it just got moved over to Ada 95 and its
 user-defined storage pools.
 
@@ -339,7 +339,7 @@
 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
+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>>
@@ -356,9 +356,9 @@
 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
+For one of the calls of Allocate described above, @i<P> (equivalent to @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
@@ -377,31 +377,31 @@
 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.
+of the collection of @i<T>. For such a call of Deallocate, @i<P> (equivalent to
+@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
+@xhang<@xterms<3.>Free(X), when X is not equal to @b<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.
+@i<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
+@xhang<@xterms<3.>Free(X), when X is not equal to @b<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