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

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

--- ai05s/ai05-0107-1.txt	2008/10/25 04:53:14	1.3
+++ ai05s/ai05-0107-1.txt	2009/05/24 03:42:49	1.4
@@ -1,4 +1,4 @@
-!standard 7.6.1(20)                                            08-08-07  AI05-0107-1/01
+!standard 7.6.1(20)                                            09-05-23  AI05-0107-1/02
 !standard 13.11(16)
 !standard 13.11(21)
 !standard 13.11.2(9/2)
@@ -12,11 +12,11 @@
 !summary
 
 If an allocator fails (raises an exception), the implementation is allowed to 
-immediately finalize any components previously initialized and then to call
+immediately finalize any components previously initialized and then call
 Deallocate the appropriate number of times to free the memory.
 
 The Allocate and Deallocate procedures of a storage pool can be implicitly
-called at during the execution of allocators, assignment operations,
+called during the execution of allocators, assignment operations,
 build-in-place aggregates and return statements, and (for Deallocate),
 during an instance of Unchecked_Deallocation.
 
@@ -51,12 +51,12 @@
       Implementation Permissions
 
 If the execution of an allocator propagates an exception, any parts of the
-allocated object that were successfully initialized can be finalized as
+allocated object that were successfully initialized may be finalized as
 part of the finalization of the innermost master enclosing the allocator.
 
 AARM Reason: This allows deallocating the memory for the allocated object
 at the innermost master, preventing a storage leak. Otherwise, the
-object would have to stay around until the the finalization of the collection
+object would have to stay around until the finalization of the collection
 that it belongs to, which could be the entire life of the program if the
 associated access type is library level.
 
@@ -67,49 +67,65 @@
 pool is a user-defined object, then the storage is allocated by calling Allocate
 as described below.
 
-[Editor's note: How calls operate should be in dynamic semantics, and the rules
-need to apply to more than just allocators anyway, so I split them out.]
+[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):
 
-Dynamic Semantics
+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:
 
 * During the execution of an allocator of type T;
 
-* During the execution an aggregate that is built-in-place in the result of
-  an allocator of type T;
+AARM Ramification: This includes during the evaluation of the initializing expression
+such as an aggregate; this is important if the initializing expression is
+built in place. We need to allow allocation to be deferred until the size of the
+object is known.
 
 * During the execution of a return statement for a function whose result is
   built-in-place in the result of an allocator of type T;
 
-* During the execution of an assignment operation of an allocated object of
-  type T with a part that has an unconstrained discriminated subtype with
+AARM Reason: We need this bullet as well as the preceding one in order that exceptions
+that propagate from such a call to Allocate can be handled within the return statement.
+We don't want to require the generation of special handling code in this unusual case,
+as it would add overhead to most return statements of composite types.
+
+* During the execution of an assignment operation with a target of an allocated
+  object of type T with a part that has an unconstrained discriminated subtype with
   defaults.
 
+AARM Reason:
+We allow Allocate to be called during assignment of objects with mutable parts so
+that mutable objects can be implemented with reallocation on assignment.
+(Unfortunately, the term "mutable" is only defined in the AARM, so we have to use
+the long-winded wording shown here.)
+
 AARM Discussion: Of course, explicit calls to the procedure are also allowed and
 are not bound by any of the rules found here.
 
-AARM Reason:
-We allow Allocate to be called during build-in-place operations so that the
-allocation can be deferred until the size of the object is known. We allow
-Allocate to be called during assignment of objects with mutable parts so that
-mutable objects can be implemented with reallocation on assignment. (Unfortunately,
-the term "mutable" is only defined in the AARM, so we have to use the long-winded
-wording shown here.)
-End AARM Reason.
-
 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
 D'Max_Size_In_Storage_Elements, where D is the designated subtype of T.
-The Alignment parameter is D'Alignment. 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 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
+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. 
+
+[Editor's Note: The above paragraph contains the changes made by AI05-0116-1.]
 
 The number of calls to Allocate needed to implement an allocator for any
 particular type is unspecified. The number of calls to Deallocate
@@ -120,12 +136,9 @@
 AARM Reason: This supports objects that are allocated in one or more parts. The
 second sentence prevents extra or missing calls to Deallocate.
 
-[Editor's note: should the number of Allocate calls be implementation-defined
-instead? Also see the !discussion.]
-
 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,
-at the places when an Allocate call is allowed for P or
+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
@@ -168,10 +181,10 @@
 
 !discussion
 
-The definition of "built-in-place" is as defined in AI05-0067-1.
+We are using the definition of "built in place" as defined by AI05-0067-1.
 
-The intent is that these rules give additional permissions to implementations;
-they are not intended to put any new requirements on implementations.
+These rules give additional permissions to implementations; they are not
+intended to put any new requirements on implementations.
 
 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
@@ -181,31 +194,6 @@
 simplify the wording somewhat at the cost of more unusual cases potentially
 being allowed. The right trade-off is not completely clear.
 
-Here is some simpler wording:
-
-  The Allocate procedure of a user-defined storage pool may only be called by
-  the implementation:
-
-  * During the execution of an allocator;
-
-  * During the execution an aggregate that is built-in-place;
-
-  * During the execution of a return statement for a function whose result is
-    built-in-place;
-
-  * During the execution of an assignment operation of an object with
-    a part that has an unconstrained discriminated subtype.
-
-This drops three things that aren't really necessary: the specification of which
-pool we are talking about; the requirement for the object to be allocated
-in the other bullets, and the requirement for defaults
-on the unconstrained discriminated part. In the first case, it's not clear
-that there is any realistic chance of an implementation calling Allocate on
-other kinds of objects. In the second case, the only additional cases allowed
-would be top-level objects constrained by their initial value, which seems
-harmless. (Unconstrained discriminated components without defaults are
-indefinite and thus are illegal.)
-
 ---
 
 AARM 13.11(16.a) says that multiple calls to Allocate are OK, so the rule to
@@ -214,7 +202,7 @@
 calls are allowed. OTOH, the rule stating the number of calls to Deallocate
 are the same is needed. It disallows Deallocate from being called multiple
 times with the same parameters (different, unrelated parameters are not allowed
-by other rules).
+by other implementation requirements).
 
 The rules about the parameters to Deallocate needing to be the same as the
 Allocate call were moved from 13.11.2 to 13.11, as they apply
@@ -290,7 +278,7 @@
 for the dynamically sized string data part) at (1). At (2), the original dynamically
 allocated string part is Deallocated and then a new, larger dynamically sized string
 part is allocated. This is an assignment statement, and that is not one of the
-classic places.
+classic places for allocation.
 
 In this interpretation, we need to do nothing to allow allocation and deallocation
 anywhere. But it's not clear that the language allows that; it should. The author's

Questions? Ask the ACAA Technical Agent