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

--- ai05s/ai05-0190-1.txt	2010/02/25 05:01:43	1.4
+++ ai05s/ai05-0190-1.txt	2010/10/26 01:38:14	1.5
@@ -1,4 +1,4 @@
-!standard D.7(8)                                10-02-24  AI05-0190-1/03
+!standard D.7(8)                                10-10-22  AI05-0190-1/04
 !class amendment 09-11-03
 !status work item 09-11-03
 !status received 09-11-03
@@ -67,7 +67,10 @@
 within the immediate scope of the pragma to be either null or the pool denoted
 by the *storage_pool*_name, except within the immediate scope of another pragma
 Default_Storage_Pool. Redundant[Thus, an inner pragma overrides an outer one.]
+The pragma applies to all nonderived access types declared in the places
+defined here, including within an instance of a generic unit.
 
+
 A pragma Default_Storage_Pool shall not be used as a configuration pragma within
 the immediate scope of another such pragma.
 
@@ -89,7 +92,8 @@
 
                               Static Semantics
 
-For an access type to which no Storage_Pool nor Storage_Size clause applies:
+For an access type to which neither Storage_Pool nor Storage_Size clause
+applies:
 
     If the default pool is null, the Storage_Size attribute is defined
     by the language to be zero.
@@ -100,10 +104,9 @@
 
     Otherwise, Redundant[there is no default pool]; the Storage_Pool
     attribute is implementation defined.
-
-AARM Ramification: Default_Storage_Pool is the only way to specify the storage pool for an anonymous access type.
 
-If an object has a coextension, the coextension is always allocated in the same pool as the object.
+AARM Ramification: Default_Storage_Pool is the only way to specify the storage
+pool for an anonymous access type.
 
 !discussion
 
@@ -483,5 +486,115 @@
 > such things...
 
 Probably because the last Legality Rule depends on it slightly.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, October 22, 2010  11:15 AM
+
+Here's a new version of AI05-0190-1, Global storage pool controls.
+It addresses all of the points from the Valencia minutes, except one, which I
+will discuss separately.
+
+[This is version /04 of the AI - RLB.]
+
+****************************************************************
+
+From: Bob Duff
+Sent: Friday, October 22, 2010  11:26 AM
+
+The one point I didn't address is this one:
+
+    Tucker makes the claim that access parameters should also be excepted from
+    the rules about the default pool. Randy says that the point was to get user
+    control over all allocators. Tucker claims that these items are on the
+    stack, and should never be allocated anywhere else. Randy says that is not
+    what Franco and others wanted; they want all allocators to come from a
+    particular pool so that the values can be moved to other types with longer
+    lifetimes. Randy thinks that writing stack allocation as an allocator is
+    misleading to readers anyway -- if you want stack allocation, declare an
+    object! Not surprisingly, Tucker strongly disagrees and no consensus is
+    reached.
+
+I have mixed feelings about this.  On the one hand, programmers expect "new" to
+do heap allocation (possibly in a user-defined pool).  On the other hand, the
+stack allocation idea is kind of cool, efficiency-wise.  On the gripping hand,
+not all compilers do it.  GNAT, for example, leaks memory for this:
+
+    procedure Alloc is
+       procedure P (X : access String) is
+       begin
+          null;
+       end P;
+    begin
+       for X in Integer range 100_000 .. 200_000 loop
+          P (new String'(1..X => 'x'));
+       end loop;
+    end Alloc;
+
+(So badly that it took 5 minutes to notice the Control-C when I tried to kill
+the program.  Linux has a bad habit of spending a lot of time paging to the disk
+instead of paying attention to my keyboard.)
+
+In any case, storage management is generally "Implementation Advice", so we
+can't really force compilers to do anything in particular.
+
+I think it would be a Bad Thing if this contentious issue sinks the AI.  The
+fact is, passing alligators to access parameters is a rare thing.  I badly want
+the ability to specify a default, and I'm willing to go either way on the issue
+of access parameters.  I'll just note that if the pragma doesn't apply to access
+parameters, then it doesn't accomplish the goal of preventing use of the
+system-provided heap.  OTOH, it accomplishes 99% of that goal, which is good
+enough for me.
+
+Please discuss.
+
+****************************************************************
+
+From: Tucker Taft
+Sent: Friday, October 22, 2010  11:55 AM
+
+Why not just say that in the presence of pragma Default_Storage_Pool(null),
+allocators for access parameters are required to be allocated on the (secondary)
+stack (or equivalently, automatically reclaimed at the end of the
+statement/declaration containing the call).
+
+It really is pretty trivial to
+implement this "optimization" and the intent of this feature was that it would
+work this way. This is indicated by AARM 13.1(25.a/2):
+
+   Implementation Note: {AI95-00230-01} For access
+   parameters and access discriminants, the "storage pool"
+   for an anonymous access type would not normally
+   exist as a separate entity. Instead, the designated
+   object of the allocator would be allocated, in the
+   case of an access parameter, as a local aliased
+   variable at the call site, and in the case of an
+   access discriminant, contiguous with the object
+   containing the discriminant. This is similar to
+   the way storage for aggregates is typically managed.
+
+We shouldn't penalize all users because some implementations haven't implemented
+the features as it was intended.  If an implementation wants to support this
+pragma, then they will have to implement this "optimization" now.
+
+This seems essentially equivalent to supporting:
+
+   Blah & Integer'Image(F(X))
+
+as a parameter.  You aren't supposed to leak storage.
+
+****************************************************************
+
+From: Bob Duff
+Sent: Monday, October 25, 2010  1:20 PM
+
+> Why not just say that in the presence of pragma
+> Default_Storage_Pool(null), allocators for access parameters are
+> required to be allocated on the (secondary) stack (or equivalently,
+> automatically reclaimed at the end of the statement/declaration
+> containing the call).
+
+OK.  New version included below.
 
 ****************************************************************