CVS difference for ais/ai-00130.txt
--- ais/ai-00130.txt 1998/09/30 00:17:23 1.1
+++ ais/ai-00130.txt 1999/03/22 22:33:21 1.2
@@ -1,24 +1,24 @@
-!standard H.4 (08) 98-04-08 AI95-00130/02
+!standard H.4 (08) 99-03-21 AI95-00130/03
!class binding interpretation 96-04-13
!status work item 96-04-17
!status received 96-04-13
!priority Medium
!difficulty Medium
-!subject Enforcing Restrictions may violate the generic contract model.
+!subject Enforcing Restrictions might violate the generic contract model.
-!summary 98-04-08
+!summary 99-03-21
-The enforcement of restrictions will generally violate the contract model
-of generics, as well as violate the "privateness" of code in a private part
+The enforcement of restrictions might violate the contract model
+of generics, as well as violate the "privateness" of code in a private part
or body.
-To be consistent with the No_Task_Hierarchy and No_Nested_Finalization
+To be consistent with the No_Task_Hierarchy and No_Nested_Finalization
restrictions, the No_Local_Allocators restriction should not preclude nested
generic instantiations. No_Nested_Finalization is broadened to cover
finalization associated with protected and task objects. For the purposes
of these checks, a generic template is logically expanded at the point
of each instantiation, the type definition for a record or protected
-type is logically expanded at the point of any default-initialized object
+type is logically expanded at the point of any default-initialized object
creation, and default parameter expressions are inserted where used.
@@ -36,40 +36,35 @@
The restrictions No_Task_Hierarchy and No_Nested_Finalization do not prohibit
such instantiations.
-!recommendation 98-04-08
+!recommendation 99-03-21
An implementation supporting the No_Task_Hierarchy, No_Nested_Finalization, or
No_Local_Allocators restrictions must enforce the intent of these restrictions
-with compile-time and/or post-compilation checks.
+with compile-time and/or post-compilation checks.
-For the purposes of these checks:
+For the purposes of these checks:
- Generic instances are logically expanded at the point of instantiation;
- If an object of a type is declared or allocated and not explicitly
- initialized, then all expressions appearing in the definition for
- the type and any of its ancestors are presumed to be evaluated
- (even for components that are not present in the created object).
+ initialized, then all expressions appearing in the definition for
+ the type and any of its ancestors are presumed to be evaluated.
- - Default formal parameters are presumed to be evaluated only if the
- corresponding actual parameter is not provided in a given call or
+ - Default formal parameters are presumed to be evaluated only if the
+ corresponding actual parameter is not provided in a given call or
instantiation;
- - Data flow information is not to be used; even "dead" code
- should be checked for violations. (??? Is this burdensome
- for implementations that completely remove dead code
- early? It seems "safe" to ignore dead code so long as
- it is "really" dead, i.e., no object code is generated for
- it, but of course the check then becomes overly permissive
- and hence not as portable. ???)
+ - Notwithstanding the above, for code which is recognized at compile-time
+ as unreachable, and for which no object code is generated,
+ implementations are permitted to omit these checks.
No_Task_Hierarchy means that only tasks directly dependent on the master
-representing the execution of the environment task (body) are permitted.
-Tasks dependent on masters which correspond to other bodies or blocks are
+representing the execution of the environment task (body) are permitted.
+Tasks dependent on masters which correspond to other bodies or blocks are
not permitted, even if these masters are executed by the environment task.
-No_Nested_Finalization should be broadened to mean that objects
-requiring finalization due to having a controlled, protected, or task
+No_Nested_Finalization should be broadened to mean that objects
+requiring finalization due to having a controlled, protected, or task
part are not permitted unless they are at the library level.
No_Local_Allocators means that allocators are prohibited in subprograms,
@@ -78,33 +73,51 @@
logically expanded at the point of instantiation for the purposes
of this check.
-!wording 98-04-08
+!wording 99-03-21
-!discussion 98-04-08
+Paragraph H.4(8) should be revised to say simply:
+ No_Local_Allocators
+
+ Allocators are prohibited in subprograms, generic subprograms, tasks,
+ and entry bodies.
+
+Paragraph D.7(4) should be revised to say:
+
+ No_Nested_Finalization
+
+ Objects with controlled, protected, or task parts, and access types
+ that designate such objects, shall be declared only at library level.
+
+Paragraph 13.12(8) should be augmented to include rules for how the
+enforcement of restrictions relates to the expansion of generic
+instantiations, default initializations, and default parameters.
+
+!discussion 99-03-21
+
Precluding nested generic instances for the No_Local_Allocators restriction
in H.4(8) in an attempt to preserve a generic control model for restrictions
is inconsistent with the rules for No_Task_Hierarchy given in D.7(3) and
for No_Nested_Finalization given in D.7(4). In general, enforcing
-pragma Restrictions across a partition will necessarily violate the
-"privateness" of a private part or a body, as well as the generic contract
-model.
+pragma Restrictions across a partition will necessarily violate the
+"privateness" of a private part or a body, as well as the generic contract
+model.
Although it might be useful to know that if a generic body
does not by itself violate a restriction, then neither will any
instantiation, enforcing this kind of "contract" rule for restrictions
that distinguish library level from non-library level usages would
overly limit the nested instantiations of useful, benign generics.
-Furthermore, the pragma Restrictions is primarily designed to
+Furthermore, the pragma Restrictions is primarily designed to
support application environments where schedulability
and formal verification requirements dictate that generics
-can only be certified with respected to particular instantiations --
-never in the abstract.
+can only be certified with respected to particular instantiations --
+never in the abstract.
A more serious problem with the rules given for the No_Task_Hierarchy
restriction in D.7(3), No_Nested_Finalization in D.7(4), and
No_Local_Allocators in H.4(8), is that they do not properly
-account for violations appearing in expressions used for default
+account for violations appearing in expressions used for default
parameters and for default initialization.
For example, the following partition obeys the static criteria given in H.4(8)
@@ -128,28 +141,31 @@
To close such loopholes, it is necessary to logically substitute
default initialization and default parameters in line at the point
-of usage. However, more or less sophisticated flow analysis might
-affect which of the expressions appearing in a record or protected type
-definition are presumed to be evaluated as part of the creation of a
-default-initialized object of such a type.
-
-To establish implementation-independent rules for enforcing restrictions,
-we choose to follow the lead established by the "freezing" rules where
-all expressions in a type definition are presumed to be evaluated
-if any are evaluated (13.14(15)), whereas expressions for default
-parameters are only relevant where the corresponding actual parameter
-is omitted (13.14(5,14)). Unlike the freezing rules, an explicitly
-initialized object is not presumed to evaluate any of the expressions
-inside the corresponding type definition as part of its creation; only
-a default initialized object will cause this.
+of usage.
-!appendix 98-03-16
+To ease the burden for implementations which check these restrictions
+as part of the insertion of dynamic semantics, implementations are
+permitted to omit the checks within constructs which generate no
+object code, because they are recognized as unreachable. Code
+which presumes a given implementation takes advantage of this permission
+is clearly less portable.
+
+For an implementation that shares code between generic instantiations,
+it might be necessary for it to collect information while compiling a generic
+body which would allow the implementation to determine at link-time
+whether particular instantiations do or do not violate these
+restrictions. This is similar to other information gathering that
+is required of all implementations as part of implementing the
+Restrictions pragma, so this is not felt to be unduly burdensome.
-[Note: The following comment inadvertently refers to H.4(08) as G.4(08).]
+!appendix 99-03-21
-!section G.4(08)
+[Note: The original comment inadvertently referred to G.4(08)
+ rather than H.4(08). We have changed those references to H.4 here.]
+
+!section H.4(08)
!subject Should No_Local_Allocators disallow nested instantiations?
-!reference RM95-G.4(08)
+!reference RM95-H.4(08)
!from Bob Duff
!reference 96-5477.a Robert A Duff 96-4-12>>
!discussion
@@ -227,9 +243,9 @@
****************************************************************
-!section G.4(08)
+!section H.4(08)
!subject Should No_Local_Allocators disallow nested instantiations?
-!reference RM95-G.4(08)
+!reference RM95-H.4(08)
!reference 96-5478.a Robert A Duff 96-4-12
!from Robert I. Eachus
!reference 96-5488.a Robert I. Eachus 96-4-15>>
@@ -356,5 +372,3 @@
****************************************************************
-
---------------------------------------------------------------------------------
Questions? Ask the ACAA Technical Agent