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
!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.
+ 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
+ - 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.
- All (nonenvironment) tasks shall depend directly on the environment task
- of the partition.
+Replace D.7(4/2) with:
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
- There shall be no abort_statements, and there shall be no calls on
+Replace D.7(10.1/2-10.2/2) with:
- There shall be no selective_accepts with terminate_alternatives.
+ Protected objects are declared only at library level.
- There shall be no allocators for task types or types containing task
+ Timing_Events are declared only at library level.
- 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:
- There shall be no semantic dependences on the package Dynamic_Priorities,
- and no occurrences of the attribute Priority.
+ The Boolean expression in an entry barrier is only a static Boolean
+ expression or a Boolean component of the enclosing protected object.
- 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:
- There shall be no allocators for protected types or types containing protected
- type subcomponents.
- There shall be no delay_relative_statements.
- There shall be no requeue_statements.
- There shall be no select_statements.
- There shall be no calls to the Set_Specific_Handler and Specific_Handler
- subprograms in Task_Termination.
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.
@@ -141,13 +209,17 @@
@xbullet<it is a class-wide type; or>
+** TBD ** (As are all
@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.>
-@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.
Questions? Ask the ACAA Technical Agent