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
Questions? Ask the ACAA Technical Agent