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

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

--- ai05s/ai05-0107-1.txt	2008/08/08 05:21:31	1.2
+++ ai05s/ai05-0107-1.txt	2008/10/25 04:53:14	1.3
@@ -161,7 +161,9 @@
      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.]
+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.]
 
 
 !discussion
@@ -214,23 +216,24 @@
 times with the same parameters (different, unrelated parameters are not allowed
 by other rules).
 
-Also note that the rules for calling Deallocate are given in 13.11, while the
-existing wording gives those rules in 13.11.2. It seems weird to separate
-the rules which really are paired; and the definition of a storage pool
-shouldn't be widely separated so that a potential implementer of a pool
-can find all of the important rules in one place.
-
 The rules about the parameters to Deallocate needing to be the same as the
-Allocate call was moved from 13.11.2, as they apply equally to the
-deallocations associated with failed allocators and with reallocation on
-assignment.
+Allocate call were moved from 13.11.2 to 13.11, as they apply
+equally to the deallocations associated with failed allocators and with
+reallocation on assignment. It is important that the behavior in all of these
+cases be specified, so that an implementer of a custom pool can rely on
+the behavior of the compiled code.
+
+Moreover, it is weird that the rules specifying how a pool is used by the
+implementation are separated from the definition of the pool. Moving those
+rules puts them altogether, making it easier for the implementer of custom
+pools to find them.
 
 ---
 
 The early finalization permission
 
 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
+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
 controlled components. A controlled component may finish its initialization
@@ -267,8 +270,8 @@
 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. Surely that is how
-our Ada 83 compiler worked, and it just got moved over to Ada 95 and its
+be called at any time that's convinient 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.
 
 For instance:
@@ -290,13 +293,22 @@
 classic places.
 
 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. My understanding
-has been that the language has always intended to allow (not require) discontiguous
-objects and reallocation on assignment as long as the high-level semantics is
-preserved. (Or I have to find a new job...) 13.11(23) seems to confirm this (as it
-wouldn't be necessary to talk about something not allowed), as do various AARM notes.
+anywhere. But it's not clear that the language allows that; it should. The author's
+understanding has been that the language has always intended to allow (not require)
+discontiguous objects and reallocation on assignment as long as the high-level
+semantics is preserved. (Or the author will need a new day job...) 13.11(23) seems
+to confirm this (as it wouldn't be necessary to talk about something not allowed),
+as do various AARM notes.
+
+One could imagine requiring that such reallocated parts be always required to be
+allocated from a system pool (rather than a user-defined pool). But that would seem to
+defeat the purpose of user-defined pools: the actual data (and the bulk of the storage)
+would be in the system pool, not the user-defined pool. It makes much more sense to
+allocate all of the parts of an object from the same pool; again, 13.11(23) appears
+to confirm that was the intent.
 
-As such, I've written the rules to make it clear that this implementation is allowed.
+As such, the rules have been written to make it clear that this implementation is
+allowed.
 
    
 

Questions? Ask the ACAA Technical Agent