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

--- ai05s/ai05-0013-1.txt	2008/01/22 06:19:13	1.11
+++ ai05s/ai05-0013-1.txt	2008/03/07 06:15:18	1.12
@@ -1,11 +1,13 @@
-!standard 7.6(9.4/2)                                 08-01-21    AI05-0013-1/10
+!standard 7.6(9.4/2)                                 08-02-21    AI05-0013-1/11
 !standard 13.12(8)
 !standard D.7(3)
 !standard D.7(4/2)
+!standard D.7(10/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 ARG Approved  7-1-1  08-02-08
 !status work item 06-05-29
 !status ARG Approved  11-0-1  06-11-18
 !status work item 06-04-10
@@ -17,8 +19,14 @@
 
 !summary
 
-(See recommendation.)
+Change the No_Nested_Finalization check to disallow allocators of nested
+access types which designate types that need finalization, and delete the
+coextension rule from the definition of "needs finalization".
+
+Correct the restrictions wording to avoid "shall" as these are definitions.
 
+Clarify when (if ever) restrictions are checked.
+
 !question
 
 7.6(9.4) says that "A type is said to need finalization if ... it is a
@@ -47,9 +55,7 @@
 
 !recommendation
 
-Change the No_Nested_Finalization check to disallow allocators of nested
-access types which designate types that need finalization, and delete the
-coextension rule from the definition of "needs finalization".
+(See summary.)
 
 !wording
 
@@ -73,23 +79,40 @@
           the units comprising the partition and is 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.
+          of the program, as indicated by the specification of runtime
+          behavior associated with a violation of the requirement.
+
+          AARM Ramification: In this case, there is no post-compilation check
+              required.
    
 Replace D.7(3/2) with:
-   No task depends on another task other than the environment task of
+   No task depends on a task other than the environment task of
    the partition.
 
+   AARM Ramification: This disallows any function returning an object with
+   a task part or coextension, even if called at the library level,
+   as such a task would temporarily depend on a nested master (the master
+   of the return statement), which is disallowed by this restriction.
+
 Replace D.7(4/2) with:
 
 No_Nested_Finalization
    Objects of a type that needs finalization (see 7.6) are declared
-   only at library level. There are no allocators where the type
-   determined by the subtype_mark of the subtype_indication or qualified_expression
-   needs finalization where the type of the allocator does not have
-   library-level accessibility.
+   only at library level. If an access type does not have library-level
+   accessibility, then there are no allocators of the type where the type
+   determined by the subtype_mark of the subtype_indication or
+   qualified_expression needs finalization.
+
+Modify D.7(10/2) as follows:
+
+No_Dynamic_Attachment
+   There is no {use of}[call to] to any of the operations defined in package
+   Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler,
+   Exchange_Handler, Detach_Handler, and Reference).
 
+   AARM Ramification: This includes 'Access and 'Address of these operations,
+   as well as inherited versions of these operations.
+
 Replace D.7(10.1/2-10.2/2) with:
 
 No_Local_Protected_Objects 
@@ -101,8 +124,8 @@
 Replace D.7(10.8/2) with:
 
 Simple_Barriers 
-   The Boolean expression in an entry barrier is only a static Boolean
-   expression or a Boolean component of the enclosing protected object.
+   The Boolean expression in each entry barrier is either a static expression
+   or a name that statically denotes a component of the enclosing protected object.
 
 !discussion
 
@@ -127,7 +150,7 @@
 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.
+that use "shall", and some that need clearer wording.
 
 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
@@ -151,56 +174,21 @@
 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.
+Restriction No_Dynamic_Attachment talks about "calls". What about uses of
+the 'Access attribute, or uses of derived subprograms? Those need to be
+disallowed, too.
+
+Restriction No_Task_Hierarchy effectively requires that no function return
+a task or an object with a task part or coextension. That's because the
+task is initially created on the master of the return statement (before
+being moved to master of the call site), and that master violates the
+restriction.
+
+We have concluded that this behavior for the restriction is acceptable,
+as returning tasks in this way is complex, and this restriction is part
+of the Ravenscar profile. Moreover, eliminating the master hand-off for
+Ravenscar would make the semantics subtly different for Ravenscar programs.
+That does not seem desirable.
 
 
 !corrigendum 7.6(9.4/2)
@@ -212,9 +200,34 @@
 @xbullet<it is a class-wide type; or>
 
 !corrigendum 13.12(8)
+
+@drepl
+A @fa<pragma> Restrictions is a configuration pragma; unless otherwise specified
+for a particular restriction, a partition shall obey the restriction if a
+@fa<pragma> Restrictions applies to any compilation unit included in the partition.
+@dby
+A @fa<pragma> Restrictions is a configuration pragma.
+If a @fa<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:
+@xbullet<A restriction may impose requirements on some or all of the units
+comprising the partition. Unless otherwise specified for a
+particular restriction, such a requirement applies to all of
+the units comprising the partition and is enforced via a
+post-compilation check.>
+@xbullet<A restriction may impose requirements on the runtime behavior
+of the program, as indicated by the specification of runtime
+behavior associated with a violation of the requirement.>
 
-** TBD ** (As are all
+!corrigendum D.7(3/2)
 
+@drepl
+@xindent<All (nonenvironment) tasks depend directly on the environment task
+of the partition.>
+@dby
+@xindent<No task depends on a task other than the environment task of
+the partition.>
+
 !corrigendum D.7(4/2)
 
 @drepl
@@ -222,10 +235,42 @@
 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 declared
-only at library level. There are no @fa<allocator>s where the type
+only at library level. If an access type does not have library-level
+accessibility, then 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>
-does not have library-level accessibility.>
+@fa<qualified_expression> needs finalization.>
+
+!corrigendum D.7(10/2)
+
+@drepl
+@xindent<There is no call to to any of the operations defined in package
+Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler,
+Exchange_Handler, Detach_Handler, and Reference).>
+@dby
+@xindent<There is no use of to any of the operations defined in package
+Interrupts (Is_Reserved, Is_Attached, Current_Handler, Attach_Handler,
+Exchange_Handler, Detach_Handler, and Reference).>
+
+!corrigendum D.7(10.1/2)
+@drepl
+@xindent<Protected objects shall be declared only at library level.>
+@dby
+@xindent<Protected objects are declared only at library level.>
+
+!corrigendum D.7(10.2/2)
+@drepl
+@xindent<Timing_Events shall be declared only at library level.>
+@dby
+@xindent<Timing_Events are declared only at library level.>
+
+!corrigendum D.7(10.8/2)
+@drepl
+@xindent<The Boolean expression in an entry barrier shall be either a static Boolean
+expression or a Boolean component of the enclosing protected object.>
+@dby
+@xindent<The Boolean expression in each entry barrier is either a static expression
+or a name that statically denotes a component of the enclosing protected object.>
+
 
 !ACATS test