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

--- ai05s/ai05-0013-1.txt	2007/12/13 04:39:34	1.8
+++ ai05s/ai05-0013-1.txt	2008/01/18 07:45:24	1.9
@@ -1,5 +1,10 @@
-!standard 7.6(9.4/2)                                 07-11-19    AI05-0013-1/07
+!standard 7.6(9.4/2)                                 07-01-17    AI05-0013-1/08
+!standard 13.12(8)
+!standard D.7(3)
 !standard D.7(4/2)
+!standard D.7(10.1/2)
+!standard D.7(10.2/2)
+!standard D.7(10.8/2)
 !class binding interpretation 06-04-10
 !status work item 06-05-29
 !status ARG Approved  11-0-1  06-11-18
@@ -52,11 +57,29 @@
 
 it is a class-wide type; or
 
-Replace D.7(3-10/2) with:
+In 13.2(8), replace
+    A pragma Restrictions is a configuration pragma; unless otherwise
+    specified for a particular restriction, a partition shall obey the
+    restriction if a pragma Restrictions applies to any compilation unit
+    included in the partition.
+with
+    A pragma Restrictions is a configuration pragma.
+    If a pragma Restrictions applies to any compilation unit included in
+    the partition, this may impose either (or both) of two kinds of
+    requirements, as specified for the particular restriction:
+        - A restriction may impose requirements on the units comprising
+          the partition which are enforced via a post-compilation
+          check.
+        - A restriction may impose requirements on the runtime behavior
+          of the program. In this case, and only in this case, the
+          runtime behavior associated with a violation of the requirement
+          will be specified.
+   
+Replace D.7(3/2) with:
+   No task depends on another task other than the environment task of
+   the partition.
 
-No_Task_Hierarchy
-   All (nonenvironment) tasks shall depend directly on the environment task
-   of the partition.
+Replace D.7(4/2) with:
 
 No_Nested_Finalization
    Objects of a type that needs finalization (see 7.6) are declared
@@ -65,50 +88,20 @@
    needs finalization where the type of the allocator does not have
    library-level accessibility.
 
-No_Abort_Statements
-   There shall be no abort_statements, and there shall be no calls on 
-   Task_Identification.Abort_Task.
+Replace D.7(10.1/2-10.2/2) with:
 
-No_Terminate_Alternatives
-   There shall be no selective_accepts with terminate_alternatives.
+No_Local_Protected_Objects 
+   Protected objects are declared only at library level.
 
-No_Task_Allocators
-   There shall be no allocators for task types or types containing task
-   subcomponents.
+No_Local_Timing_Events 
+   Timing_Events are declared only at library level.
 
-No_Implicit_Heap_Allocations
-   There shall be no operations that implicitly require heap storage allocation
-   to be performed by the implementation. It is implementation defined which 
-   operations implicitly require heap storage allocation.
+Replace D.7(10.8/2) with:
 
-No_Dynamic_Priorities
-   There shall be no semantic dependences on the package Dynamic_Priorities,
-   and no occurrences of the attribute Priority.
+Simple_Barriers 
+   The Boolean expression in an entry barrier is only a static Boolean
+   expression or a Boolean component of the enclosing protected object.
 
-No_Dynamic_Attachment
-   There shall be no call to any of the operations defined in package Interrupts
-   (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler, Exchange_Handler,
-   Detach_Handler, and Reference).
-
-Replace D.7(10.3/2-10.7/2) with:
-
-No_Protected_Type_Allocators
-   There shall be no allocators for protected types or types containing protected
-   type subcomponents.
-
-No_Relative_Delay
-   There shall be no delay_relative_statements.
-
-No_Requeue_Statements
-   There shall be no requeue_statements.
-
-No_Select_Statements
-   There shall be no select_statements.
-
-No_Specific_Termination_Handlers
-   There shall be no calls to the Set_Specific_Handler and Specific_Handler 
-   subprograms in Task_Termination.
-
 !discussion
 
 Directly attempting to fix problem (2) leads into a rat-hole of bad or
@@ -128,11 +121,86 @@
 
 During editorial review it was noted that the wording of D.7 is weird
 because it uses sometimes "shall" and sometimes "is".  This is 
-inconsistent, and furthermore the meaning of "is" is unclear because we 
-don't know if it's describing a rule that the user must adhere to, or the 
-semantics of the language, or what (D.7(3) is especially bad).  So we are 
-fixing the entire section.
+inconsistent. As this is static semantics (the actual check is defined
+in 13.12), all of these should use "is". That sometimes is confusing (it isn't
+clear on whom the restriction applies); it is best to word these
+in terms of what is *not* allowed. We are fixing all of the restrictions
+that violate either of these.
+
+The most pervasive problem in the specification of restrictions is the
+failure to follow up on 13.12(8), which states that a restriction is
+subject to enforcement via a post-compilation check "unless otherwise
+specified for a particular restriction". There does not exist even one
+restriction to which this "unless otherwise specified" clause applies,
+even though many restrictions cannot be checked statically.
+
+The proposed new version of 13.12(8) is an attempt to address this issue.
+This change takes care of, for example, all of the restrictions defined in
+the "Dynamic Semantics" section of D.7 as well as No_Exceptions, No_Recursion,
+and No_Reentrancy. All of these have the property that "the runtime behavior
+associated with a violation of the requirement" is specified (even if it
+is only specified to be implementation dependent) and therefore no
+post-compilation check is called for.
+
+It is important to note that a given restriction may impose both kinds of
+requirements. For instance, the No_Exceptions restriction has this property.
+Statically, exception declarations and raise statements are disallowed.
+Dynamically, an execution which would normally raise an exception due to
+a failed runtime check becomes erroneous. Any proposed changes to 13.12(8)
+should be reviewed with this example in mind.
+
+Some questions about individual restrictions:
+  Immediate_Reclamation -
+    What does this "restriction" mean? Does it have any static
+    semantics? Does it have any dynamic semantics?
+
+  No_Dynamic_Attachment -
+    This restriction talks about "calls". What about uses of the 'Access
+    attribute, or uses of derived subprograms? Referring only to calls
+    might be ok if this restriction were to be enforced dynamically,
+    but that is not the case.   
+    
+  No_Task_Hierarchy -
+    I think that if we want this one to be statically checkable, then
+    we should reject any function whose result type has a task part,
+    regardless of how the function is used. Note that the restriction
+    would not have to disallow a function with a limited classwide result
+    type, but then it would have to disallow the case where such a function
+    attempts to return a value of a specific type that has a task part.    
+    
+    It seems desirable that a program which never declares a task or
+    task type should not run afoul of this restriction.
+
+    Things get complicated if we try to allow something like
+    
+       with Function_That_Returns_A_Task;
+       package Static_Scope is
+         X : Some_Type := Function_That_Returns_A_Task;
+       end Static_Scope;
+       
+    while still properly rejecting all the cases that need to be rejected
+    involving, for example, an access-to-function type with a limited
+    classwide result type.
+    
+    In the interests of simplicity, it might also be a good idea if this
+    restriction were to disallow any allocator where the type of
+    the allocated object has a task part and the type of the allocator is
+    anonymous. Otherwise we get into interactions with AI05-0051 and there
+    might also be problems with coextensions. This rule is conservative;
+    the following harmless example would be disallowed:
+    
+        package Static_Scope is ... end Static_Scope;
+        package body Static_Scope is
+          task type Tsk;
+          type body Tsk is ... ;
+          type Rec is record Ref : access Tsk; end record;
+          Y : Rec := (Ref => new Tsk);
+        end Static_Scope;
+        
+     If this is viewed as a problem, a more precise (and more complicated)
+     rule could be formulated.
 
+
 !corrigendum 7.6(9.4/2)
 
 @drepl
@@ -141,13 +209,17 @@
 @dby
 @xbullet<it is a class-wide type; or>
 
+!corrigendum 13.12(8)
+
+** TBD ** (As are all
+
 !corrigendum D.7(4/2)
 
 @drepl
 @xindent<Objects of a type that needs finalization (see 7.6) and access types that
 designate a type that needs finalization, shall be declared only at library level.>
 @dby
-@xindent<Objects of a type that needs finalization (see 7.6) are be declared
+@xindent<Objects of a type that needs finalization (see 7.6) are declared
 only at library level. There are no @fa<allocator>s where the type
 determined by the @fa<subtype_mark> of the @fa<subtype_indication> or
 @fa<qualified_expression> needs finalization where the type of the @fa<allocator>
@@ -571,6 +643,20 @@
 Having said all that, I must say: I think this issue is a storm in a coffee
 carafe (tempest in a teapot?), and I therefore have no strong objection to the
 negative wordings you suggested.  I just don't think it's necessary.
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, January 18, 2008  12:05 AM
+
+> Here are my AIs for Tampa. [This is AI05-0013-1/08 - ED].
+
+Your proposed rewording of 13.12(8) has lost the "unless otherwise specified".
+There are restrictions (those in 13.12.1 in particular) that do not apply
+partition-wide. That needs to be reflected in this wording somehow.
+
+One of us forgot to change away from the rejected "shall" wording. I've
+done that, and made a few edits to the discussion.
 
 ****************************************************************