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

Differences between 1.4 and version 1.5
Log of other versions for file ai12s/ai12-0319-1.txt

--- ai12s/ai12-0319-1.txt	2019/03/12 03:49:28	1.4
+++ ai12s/ai12-0319-1.txt	2019/03/20 03:43:25	1.5
@@ -1,5 +1,5 @@
-!standard 9.5(47/5)                                  19-03-11  AI12-0319-1/03
-!standard 9.5(69/5)
+!standard 9.5(47/5)                                  19-03-19  AI12-0319-1/04
+!standard 9.5(68/5)
 !standard 13.11(15)
 !standard 13.11(17)
 !standard 13.11(18/4)
@@ -87,18 +87,19 @@
 could be considered to be class-wide (Root_Storage_Pool'Class). It didn't seem
 worth spelling this out somewhere.]
 
-Add after 9.5(69/5): [Legality Rules]
+Add after 9.5(68/5): [Legality Rules]
 
 For a composite type that is nonblocking:
 
     * All component subtypes shall be nonblocking;
-    * For a record type or extension, every call in each default 
-      initialization expression shall call an operation that is nonblocking;
+    * For a record type or extension, every call in the default_expression
+      of a component (including discriminants) shall call an operation that is 
+      nonblocking;
     * For a controlled type, the Initialize, Finalize, and Adjust (if any) 
       subprograms shall be nonblocking.
  
     AARM Ramification: Default initialization, finalization, and assignment 
-    of elementary types is always nonblocking, so we don't need any rules 
+    of elementary types are always nonblocking, so we don't need any rules 
     for those.
 
 Add after AARM 9.5(82.e/5): [About assume-the-worst checking in generic bodies]
@@ -125,11 +126,19 @@
 
 Add to 13.11(15):
 
-If the nominal subtype of the name specified for Storage_Pool is nonblocking, 
-then the primitive Allocate, Deallocate, and Storage_Size subprograms of that 
-type shall be nonblocking. Additionally, if the pool that is one that supports 
-subpools (see 13.11.4), the primitive Default_Subpool_for_Pool, 
-Allocate_From_Subpool, and Deallocate_Subpool subprogram shall be nonblocking.
+If the nominal subtype of the name specified for Storage_Pool is 
+nonblocking (see 9.5), then the primitive Allocate, Deallocate, and 
+Storage_Size subprograms of that type shall be nonblocking. Additionally, if 
+the pool that is one that supports subpools (see 13.11.4), the primitive 
+Default_Subpool_for_Pool, Allocate_From_Subpool, and Deallocate_Subpool 
+subprograms shall be nonblocking.
+
+   AARM Reason: We need to be able to describe in contracts (especially for
+   generic units) whether the operations of a storage pool allow blocking, and 
+   we do that with the nonblocking status of the type. We make the check when 
+   the pool is specified so we can avoid adding a special check to the 
+   declaration of a pool type - we want pool types to follow the same rules 
+   as any other type.
 
 Add after 13.11(17):
 
@@ -137,7 +146,7 @@
 and Storage_Size subprograms for the standard pool(s) are nonblocking.
 
    AARM Reason: We need to specify that the type is nonblocking so that an 
-   instance of  Unchecked_Deallocation is nonblocking if the object type is 
+   instance of Unchecked_Deallocation is nonblocking if the object type is 
    nonblocking (as the type is used in the contract). Ada 95 did not declare 
    standard allocation/deallocation as potentially blocking, so these things 
    can be used in protected types, and we want that to remain true (with static 
@@ -192,6 +201,89 @@
 calls rather than generic parameters for deallocation, so neither the 
 designated type(s) nor the pool type are known when it is called. So those
 cannot be described in the contract.
+
+!corrigendum 9.5(17/3)
+
+@dinsa
+In addition to the places where Legality Rules normally apply (see 12.3),
+these rules also apply in the private part of an instance of a generic unit. 
+@dinss
+Just to force a conflict; the updated text will be found in the conflict file.
+
+!corrigendum 13.11(15)
+
+@drepl
+Storage_Size or Storage_Pool may be specified for a nonderived access-to-object 
+type via an @fa<attribute_definition_clause>; the @fa<name> in a Storage_Pool 
+clause shall denote a variable.
+@dby
+Storage_Size or Storage_Pool may be specified for a nonderived access-to-object 
+type via an @fa<attribute_definition_clause>; the @fa<name> in a Storage_Pool 
+clause shall denote a variable.
+If the nominal subtype of the @fa<name> specified for Storage_Pool is 
+nonblocking (see 9.5), then the primitive Allocate, Deallocate, and 
+Storage_Size subprograms of that type shall be nonblocking. Additionally, if 
+the pool that is one that supports subpools (see 13.11.4), the primitive 
+Default_Subpool_for_Pool, Allocate_From_Subpool, and Deallocate_Subpool 
+subprograms shall be nonblocking.
+
+!corrigendum 13.11(17)
+
+@dinsa
+If Storage_Pool is not specified for a type defined by an 
+@fa<access_to_object_definition>, then the implementation chooses a standard 
+storage pool for it in an implementation-defined manner. In this case, the 
+exception Storage_Error is raised by an @fa<allocator> if there is not enough 
+storage. It is implementation defined whether or not the implementation 
+provides user-accessible names for the standard pool type(s). 
+@dinst
+The type(s) of the standard pool(s), and the primitive Allocate, Deallocate, 
+and Storage_Size subprograms for the standard pool(s) are nonblocking.
+
+!corrigendum 13.11(18)
+
+@drepl
+If Storage_Size is specified for an access type @i<T>, an
+implementation-defined pool @i<P> is used for the type. The
+Storage_Size of @i<P> is at least that requested, and the
+storage for @i<P> is reclaimed when the master containing the
+declaration of the access type is left. If the implementation cannot
+satisfy the request, Storage_Error is raised at the freezing point of
+type @i<T>. The storage pool @i<P> is used only for allocators returning type @i<T>
+or other access types specified to use @i<T>'Storage_Pool. Storage_Error is raised
+by an @fa<allocator> returning such a type if the storage space of @i<P> is
+exhausted (additional memory is not allocated).
+@dby
+If Storage_Size is specified for an access type @i<T>, an
+implementation-defined pool @i<P> is used for the type. The
+Storage_Size of @i<P> is at least that requested, and the
+storage for @i<P> is reclaimed when the master containing the
+declaration of the access type is left. If the implementation cannot
+satisfy the request, Storage_Error is raised at the freezing point of
+type @i<T>. The storage pool @i<P> is used only for allocators returning type @i<T>
+or other access types specified to use @i<T>'Storage_Pool. Storage_Error is raised
+by an @fa<allocator> returning such a type if the storage space of @i<P> is
+exhausted (additional memory is not allocated).
+The type of @i<P>, and the primitive Allocate, Deallocate, and Storage_Size 
+subprograms of @i<P> are nonblocking.
+
+!corrigendum 13.11.2(3/3)
+
+@drepl
+@xcode<@b<generic>
+   @b<type> Object(<@>) @b<is limited private>;
+   @b<type> Name   @b<is access>  Object;
+@b<procedure> Ada.Unchecked_Deallocation(X : @b<in out> Name)
+   @b<with> Convention =@> Intrinsic;
+@b<pragma> Preelaborate(Ada.Unchecked_Deallocation);>
+@dby
+@xcode<@b<generic>
+   @b<type> Object(<@>) @b<is limited private>;
+   @b<type> Name   @b<is access>  Object;
+@b<procedure> Ada.Unchecked_Deallocation(X : @b<in out> Name)
+   @b<with> Preelaborate, 
+        Nonblocking =@> Object'Nonblocking and Name'Storage_Pool'Nonblocking,
+        Convention =@> Intrinsic;>
 
 !ASIS
 

Questions? Ask the ACAA Technical Agent