CVS difference for ai12s/ai12-0003-1.txt

--- ai12s/ai12-0003-1.txt	2011/11/09 01:08:35	1.1
+++ ai12s/ai12-0003-1.txt	2012/12/01 22:48:57	1.2
@@ -1,4 +1,10 @@
-!standard 3.10.2(13.2/3)                             11-11-08    AI12-0003-1/01
+!standard 3.10.2(13.2/3)                             12-12-01    AI12-0003-1/02
+!standard 13.11.3(1/3)
+!standard 13.11.3(3.1/3)
+!standard 13.11.3(4.1/3)
+!standard 13.11.3(4.2/3)
+!standard 13.11.3(5/3)
+!standard 13.11.3(6/3)
 !class Amendment 11-06-19
 !status work item 11-06-19
 !status received 11-03-21
@@ -7,9 +13,9 @@
 !subject Default storage pool for storage pools
 !summary
 
-**TBD.
+A pragma Standard_Storage_Pool is introduced.
 
-!question
+!problem
 
 If a programmer wants to specify the default storage pool as NULL through a
 configuration pragma, then how would one provide a user defined storage pool
@@ -17,14 +23,99 @@
 
 !proposal
 
-(See wording.)
+Add a pragma to achieve the effect of returning to the "standard"
+allocation method used by the implementation, usually the use of a
+general heap.
 
 !wording
 
-** TBD.
+Reinstate 13.11.3 (1/4) to read:
+Two storage pool pragmas can be used to control the setting of a
+default storage pool for access types: Default_Storage_Pool and
+STandard_Storage_Pool.
+
+
+Add after 13.11.3 (3.1/3)
+ pragma Standard_Storage_Pool;
+ 
+
+Change 13.11.3 (3.1/3) to read:  
+{A storage pool pragma} [A pragma Default_Storage_Pool]
+is allowed immediately within the visible part of a package_specification, 
+immediately within a declarative_part, or as a configuration pragma. 
+
+Change 13.11.3 (4.1/3) from 
+  "{AI05-0190-1} If the pragma is used as a configuration pragma, the
+  storage_pool_indicator shall be null, and it defines the default
+  pool to be null within all applicable compilation units (see
+  10.1.5), except within the immediate scope of another pragma
+  Default_Storage_Pool. Otherwise, [the pragma occurs immediately
+  within a sequence of declarations, and] it defines the default pool
+  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 a later pragma Default_Storage_Pool. [Thus, an inner pragma
+  overrides an outer one.]"
+
+to 
+
+  {AI05-0190-1} If the Default_Storage_Pool pragma is used as a
+  configuration pragma, the storage_pool_indicator shall be null, and
+  it defines the default pool to be null within all applicable
+  compilation units (see 10.1.5), except within the immediate scope of
+  another storage pool pragma. Otherwise, [the pragma occurs
+  immediately within a sequence of declarations, and] it defines the
+  default pool 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 a later storage pool pragma. [Thus, an inner
+  pragma overrides an outer one.]
+
+Add after 13.11.3 (4.1/3)
+Except within the immediate scope of another storage pool pragma, the
+Standard_Storage_Pool pragma causes the storage pool of any access type 
+to be the standard storage pool as described in 13.11.
+
+<<< AI Note: the wording carefully ties into 13.11, so that it works for 
+instances. >>>>
+
+
+Change 13.11.3 (4.2/3) to read:
+
+A {storage pool} pragma [Default_Storage_Pool] shall not be used as a
+ configuration pragma that applies to a compilation unit that is
+ within the immediate scope of another {storage pool} pragma[
+ Default_Storage_Pool].
+
+<<<<< Aside: This and the other paragraphs of the section have a problem:
+"immediate scope" of pragmas is not defined ("immediate scope" is defined only 
+for declarations and for (declared) entitites. See 8.2. >>>>
+
+<<<<<< Aside 2: This issue of contradictory pragmas surely is not
+limited to the storage pool pragmas. 2a) has anybody checked the
+manual for problems with other pragmas. 2b) shouldn't this be a
+general rule on configuration pragmas?  >>>>>
+
+Modify 13.11.3 (5/3) to read  
+ This aspect overrides any {storage pool}[Default_Storage_Pool] pragma
+ that might apply to the generic unit.
+
+
+After 13.11.3 (9.c/3) add
+The pragma Standard_Storage_Pool is new.
 
 !discussion
 
+We do not want to give the standard storage pool a name, since it
+should remain implementation-defined whether, in the absence of
+user-provided storage pools, the storage pool model is used by the
+implementation at all. Specifically it might just go for the heap, or
+have a clever way of combining a general heap with pools of cached,
+equally-sized memory blocks.
+
+A pragma that causes the implementation to revert to the standard
+allocation method seemed best to achieve the desired capability.
+  
+<<<< Note the slightly unrelated problems discovered in 13.11.3 and
+particularly (4.2/3), as described in the proposal text. >>>>  
 
 !ACATS test
 
@@ -308,5 +399,27 @@
 
     type T1 is access Something;
     for T1'Storage_Size use 10_000;
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Saturday, December 1, 2012  3:01 PM
+
+[Commenting on version /02 of this AI.]
+
+<<<<<< Aside 2: This issue of contradictory pragmas surely is not limited to the storage
+pool pragmas. 2a) has anybody checked the manual for problems with other pragmas. 2b)
+shouldn't this be a general rule on configuration pragmas?  >>>>>
+
+If you're not careful, there will be an action item in your future!! :-) :-)
+
+To actually answer your question, I know that we spent quite a bit of time looking at this
+issue for Suppress and Unsuppress. So if some generalish solution is adopted, you'd have
+to be careful to ensure that it didn't apply to them (or at the very least, not change
+their behavior).
+
+But I'd actually expect this to be something that has to be addressed on a case-by-case basis
+(it depends on what the pragmas do as to how conflicts ought to be resolved). Feel free
+to prove me wrong, though.
 
 ****************************************************************