CVS difference for ais/ai-00058.txt

Differences between 1.3 and version 1.4
Log of other versions for file ais/ai-00058.txt

--- ais/ai-00058.txt	1999/03/30 00:33:08	1.3
+++ ais/ai-00058.txt	1999/10/07 00:25:06	1.4
@@ -1,5 +1,5 @@
-!standard E.2.1    (08)                               99-03-22  AI95-00058/07
-!class ramification 95-06-25
+!standard E.2.1    (08)                               99-09-26  AI95-00058/08
+!class binding interpretation 99-09-27
 !status work item 95-06-25
 !status received 95-06-25
 !priority High
@@ -65,8 +65,41 @@
 as" or "deeper than" other accessibility levels.  So what does E.2.1(8)
 mean by "accessible from"?
 
-!response
+!recommentation
 
+(See summary.)
+
+!wording
+
+Replace paragraph E.2.1(8) with this paragraph:
+
+Notwithstanding the definition of the accessibility rules given in 3.10.2,
+if the declaration of a shared passive library unit P1 depends semantically on
+a library unit P2 and if a declaration immediately within the declaration region
+of P1 is also within the scope of the with clause that specifies P2 then that
+declaration has an accessibility level no deeper than the accessibility level
+of P2.  An Accessibility_Check that involves the accessibility levels of a
+non-shared passive library unit and a shared library unit is performed and
+Program_Error is raised if the check fails.
+
+Add the following heading and paragraph after E.2.1(11):
+
+Implementation Permissions
+
+If the Accessibility_Check to be performed involves the accessibility levels
+of two shared passive library units, then an implementation need not perform
+the check.  If the implementation ensures that all shared passive library
+units have the same lifetimes as the program lifetime and are accessible
+from all partitions, then omitting such an Accessibility_Check cannot cause
+dangling references.  On the other hand, if the implementation allows
+passive partitions to be loaded and elaborated dynamically throughout the
+lifetime of the program or if some passive partitions are not accessible
+from other partitions, the undetected failure of the Accessibility_Check
+can cause dangling references; in that case, the execution of the program
+is defined be erroneous.
+
+!discussion
+
 Within a single partition, it is possible to have an access value that
 designates a library level object in any library package.  This model
 assumes that library-level data is addressable from pretty much
@@ -311,6 +344,7 @@
 place:
 
    package P1 is
+      pragma Shared_Passive(P1);
       X: aliased Integer;
    end P1;
 
@@ -637,8 +671,8 @@
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 > so the "P2.Y := P1.X'Access;" assignment would be legal.
 
-I think that this is backwards: If P2 withes P1, then we know that P1 lives 
-as least as long as P2, not the other way arround. The assignment is still 
+I think that this is backwards: If P2 withes P1, then we know that P1 lives
+as least as long as P2, not the other way arround. The assignment is still
 (or "therefore" :-) legal.
 
 Offer Pazy
@@ -659,53 +693,53 @@
 !reference 96-5768.a Offer Pazy  96-11-22>>
 !discussion
 
-I would like to start by arguing that resorting to erroneous execution in 
-this case is very bad news. The features discussed and the interactions 
-among them are not considered unsafe, they cannot be easily localized and 
-the erroneous usage is likely to result from actions of programmers on the 
-one hand and system builders on the other. Also, note that it is very likely 
-that the affected applications are (very) large programs. It is not clear to 
-me what guidelines one could give to his group to avoid such cases without 
-significantly limiting the usefulness of Annex E. Errors resulting from this 
-can be extremely subtle and very hard to find (let alone predict in advance) 
-even for a more experienced user. Most other cases where we have resorted to 
-erroneousness are either obscure or use unsafe features and hence are 
-usually marked by a pragma or a certain with clause.  This is not the case 
-here, where the constructs are "mainstream: and their usage may appear in 
+I would like to start by arguing that resorting to erroneous execution in
+this case is very bad news. The features discussed and the interactions
+among them are not considered unsafe, they cannot be easily localized and
+the erroneous usage is likely to result from actions of programmers on the
+one hand and system builders on the other. Also, note that it is very likely
+that the affected applications are (very) large programs. It is not clear to
+me what guidelines one could give to his group to avoid such cases without
+significantly limiting the usefulness of Annex E. Errors resulting from this
+can be extremely subtle and very hard to find (let alone predict in advance)
+even for a more experienced user. Most other cases where we have resorted to
+erroneousness are either obscure or use unsafe features and hence are
+usually marked by a pragma or a certain with clause.  This is not the case
+here, where the constructs are "mainstream: and their usage may appear in
 many places in the code's body.
 
-So this is my main problem and I would like the ARG to consider this AI with 
+So this is my main problem and I would like the ARG to consider this AI with
 this in mind, this is a very serious erroneousness case.
 
-Based on this general objective, I would like to propose another approach to 
-address the real problem that is expressed in the AI, and that is to abandon 
-the (very ambitious) goal of supporting in the standard the idea of 
-hierarchical memory configurations (HMCs) (those that allow passive 
-partitions to come and go). From the outset, we knew that the support of 
-this is at best partial; we leave all issues of explicit partition abort, 
-reload, and restart outside the ARM, features that must be provided in some 
-form by the implementation to support HMCs. Furthermore, the partitioning 
-and configuration steps are treated by the ARM as conceptual only, we give 
-very few hints on what they should do.  This was done intentionally since we 
+Based on this general objective, I would like to propose another approach to
+address the real problem that is expressed in the AI, and that is to abandon
+the (very ambitious) goal of supporting in the standard the idea of
+hierarchical memory configurations (HMCs) (those that allow passive
+partitions to come and go). From the outset, we knew that the support of
+this is at best partial; we leave all issues of explicit partition abort,
+reload, and restart outside the ARM, features that must be provided in some
+form by the implementation to support HMCs. Furthermore, the partitioning
+and configuration steps are treated by the ARM as conceptual only, we give
+very few hints on what they should do.  This was done intentionally since we
 understood that we cannot achieve more standardization here.
 
-Essentially, what has happened at an early stage of the mapping, was that we 
-saw this "nice feature" and thought that we could get this interesting model 
- in the annex, almost free. Later revisions, and this AI proved us wrong. In 
-order to really support HMCs, much more definition work in needed in the 
-language to do it right, and it's not easy. Furthermore, while some may 
-argue, I do believe that there are still many applications for the flat 
+Essentially, what has happened at an early stage of the mapping, was that we
+saw this "nice feature" and thought that we could get this interesting model
+ in the annex, almost free. Later revisions, and this AI proved us wrong. In
+order to really support HMCs, much more definition work in needed in the
+language to do it right, and it's not easy. Furthermore, while some may
+argue, I do believe that there are still many applications for the flat
 memory model without supporting HMCs; it's nice to have, but not critical.
-If the objective of supporting HMCs causes us to make straight-forward 
-distributed programs erroneous in a serious manner, then I think we are 
+If the objective of supporting HMCs causes us to make straight-forward
+distributed programs erroneous in a serious manner, then I think we are
 making the wrong decision.
 
-So basically, my suggestion is to give up on the standard support of HMCs. 
-We should leave this entire model as impl-defined (as is most of it now 
-anyway) and fix whatever is necessary in the accessibility rules for the 
-flat model (the AI does it already as is discussed under the third example). 
-The flat model will be the default one and the only model required by the 
-annex. Implementations will then be free to support HMCs fully and to add 
+So basically, my suggestion is to give up on the standard support of HMCs.
+We should leave this entire model as impl-defined (as is most of it now
+anyway) and fix whatever is necessary in the accessibility rules for the
+flat model (the AI does it already as is discussed under the third example).
+The flat model will be the default one and the only model required by the
+annex. Implementations will then be free to support HMCs fully and to add
 whatever pragmas or rules to address this specific problem.
 
 I think that the majority of users will gain by this!!!

Questions? Ask the ACAA Technical Agent