CVS difference for ais/ai-00130.txt

Differences between 1.1 and version 1.2
Log of other versions for file 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