CVS difference for ais/ai-00416.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00416.txt

--- ais/ai-00416.txt	2005/04/14 22:16:12	1.6
+++ ais/ai-00416.txt	2005/05/07 02:15:03	1.7
@@ -1,4 +1,5 @@
-!standard 3.2.3(01)                                     05-04-13  AI95-00416/05
+!standard 3.2.3(01)                                     05-04-17  AI95-00416/06
+!standard 3.3(10)
 !standard 3.7(27)
 !standard 3.9.2(02)
 !standard 3.9.2(04)
@@ -6,6 +7,7 @@
 !standard 3.9.2(06)
 !standard 3.9.2(11)
 !standard 3.9.2(18)
+!standard 3.10.2(07)
 !standard 3.10.2(09)
 !standard 3.10.2(10)
 !standard 3.10.2(11)
@@ -19,9 +21,13 @@
 !standard 6.5(20)
 !standard 6.5(22)
 !standard 7.6.1(03)
+!standard 7.6.1(09)
 !standard 9.2(02)
 !standard 9.2(03)
 !standard 9.2(04)
+!standard 13.11(25)
+!standard 13.11.2(9)
+!standard 13.11.2(17)
 !class amendment 05-02-07
 !status Amendment 200Y 05-03-16
 !comment This AI is in the Amendment, but is not yet approved.
@@ -87,18 +93,18 @@
 
 Caller does *not* pass in an accessibility level for return objects.
 
-Return object has accessibility between the uplevels of the function
+A return object has accessibility between the uplevels of the function
 and the return statement. Hence:
 
-   Ok for return object to point to up-levels
+   Ok for a return object to point to up-levels
    Ok for locals of return statement to point to return object
    Not Ok for locals outside return statement to point to return object
    Not Ok for up-levels to point to return object
    Not Ok for return object to point to locals
 
-Function call has accessibility level of function decl, so may *not* use
-call on local function to initialize object in longer-lived heap if it has
-an access discrim or is of a class-wide type.
+Function call has accessibility level of function declaration, so may *not* use
+a call on a local function to initialize an object in a longer-lived heap if it
+has an access discriminant or is of a class-wide type.
 
 If access discriminants are initialized individually, then type
 conversion provides for the accessibility checks. However, if the
@@ -134,6 +140,11 @@
     it has an operand whose expected type (see 8.6) is T, or if it has
     an access parameter {or access result type} (see 6.1) designating T.
 
+Change 3.3(10) as follows:
+
+   * {the return object created as} the result of evaluating a function_call
+     (or the equivalent operator invocation - see 6.6);
+
 Change 3.7(27) to:
 
     For an access discriminant, its access_definition is elaborated when
@@ -200,8 +211,16 @@
     value is perfectly acceptable, and can be a useful indication of a
     particular status of the call.
 
-Add after 3.10.2(7):
+Modify 3.10.2(7/2) as follows:
 
+    * An entity or view [created by a declaration] {defined by a declaration and
+      created as part of its elaboration} has the same accessibility
+      level as the innermost [enclosing] master that elaborates the
+      declaration {(} other than the declaration itself{)} except in the
+      cases of renaming and derived access types described below. A
+      parameter of a master has the same accessibility level as the
+      master.
+
    AARM NOTE:
      This rule defines the accessibility of all named access types, as
      well as the accessibility level of all anonymous access types other
@@ -243,7 +262,8 @@
       return statement completes normally by returning from the
       function, prior to leaving the function, the accessibility level
       of the return object changes to be a level determined by the point
-      of call.
+      of call, as does the level of any coextensions (see below) of the
+      return object.
 
     AARM Note:
       We define the accessibility level of the return object during the
@@ -298,18 +318,36 @@
 Change 3.10.2(14):
 
     * The accessibility level of an object created by an allocator is
-      the same as that of the access type, except for an allocator that
-      defines the value of an access parameter or an access discriminant.
-      For an access parameter, the accessibility level is that of the
-      master immediately enclosing the call. For an access discriminant,
-      the accessibility level is determined as follows:
+      the same as that of the access type, except for an allocator of an
+      anonymous access type that defines the value of an access
+      parameter or an access discriminant. For an allocator defining the
+      value of an access parameter, the accessibility level is that of
+      the master immediately enclosing the call. For one defining an
+      access discriminant, the accessibility level is determined as
+      follows:
+
          + for an allocator used to define the constraint in a
            subtype_declaration, the level of the subtype_declaration;
+
          + for an allocator used to define the constraint in a
            component_definition, the level of the enclosing type;
+
          + for an allocator used to define the discriminant of an object,
            the level of the object.
 
+      In this last case, the allocated object is said to be a *coextension*
+      of the object whose discriminant designates it, as well as of any
+      object of which the discriminated object is itself a coextension or
+      subcomponent.  All coextensions of an object are finalized
+      when the object is finalized (see 7.6.1).
+
+      AARM NOTE: The rules of access discriminants are such that
+      when the space for an object with a coextension is reclaimed,
+      the space for the coextensions can be reclaimed.  Hence, there
+      is implementation advice (see 13.11) that an object and its coextensions
+      all be allocated from the same storage pool (or stack frame,
+      in the case of a declared object).
+
 Add after the paragraph inserted by AI95-00344 after 4.8(5):
 
     If the designated subtype of the type of the allocator has one or
@@ -345,8 +383,20 @@
     then either the return_subtype_indication (if any) is constrained,
     or there must be a return expression.
 
-Add after 6.5(5.5/2):
+Modify 6.5(5.5/2) as follows:
 
+	For the execution of an extended_return_statement, the
+	subtype_indication or access_definition is elaborated. This creates
+	the nominal subtype of the return object. If there is a return
+	expression, it is evaluated and converted to the nominal subtype
+	(which might raise Constraint_Error  see 4.6){; the return object
+	is created} and {the converted value} becomes the initial value of
+	the return object; otherwise, the return object is {created and}
+	initialized by default as for a stand-alone object of its nominal
+	subtype (see 3.3.1). If the nominal subtype is indefinite, the
+	return object is constrained by its initial value. The
+	handled_sequence_of_statements, if any, is then executed.
+
   AARM NOTE:
     If the result type is controlled or has a controlled part, appropriate
     calls on Initialize or Adjust are performed prior to executing
@@ -392,11 +442,13 @@
                      Implementation Permission
 
      If the result subtype of a function is unconstrained,
-     and a call on the function is used to provide the initial value of
+     and a call on the function is used, directly or indirectly,
+     to provide the initial value of
      an object with a constrained nominal subtype, Constraint_Error may
-     be raised at the point of the call while elaborating a
+     be raised at the point of the call (after abandoning the
+     execution of the function body) if, while elaborating a
      return_subtype_indication or evaluating a return expression within
-     the function, if it is determined that the value of the result will
+     the function, it is determined that the value of the result will
      violate the constraint of this object's subtype.
 
    AARM NOTE: Without such a permission, it would be very difficult
@@ -419,6 +471,11 @@
      accept_statement, a block_statement, or a simple_statement]
      {a statement};
 
+Add after 7.6.1(9):
+
+     * If the object has coextensions (see 3.10.2), each coextension is finalized
+       after the object whose access discriminant designates it.
+
 Change 9.2(2):
 
      A task object (which represents one task) can be {a part of a
@@ -464,6 +521,37 @@
      the activating task being suspended until all the new tasks complete
      their activation.
 
+Change 13.11(25.1/2) as follows:
+
+    * If the allocator is [initializing an access discriminant of an object
+      of a limited type, and the discriminant is itself a subcomponent]
+      {defining a coextension (see 3.10.2)}
+      of an object being created by an outer allocator, then the storage
+      pool used for the outer allocator should also be used for the
+      [allocator initializing the access discriminant] {coextension};
+
+Change 13.11.2(9) as follows:
+
+   3. Free(X), when X is not equal to null first performs finalization {of
+      the object designated by X (and any coextensions of the object --
+      see 3.10.2)}, as described in 7.6{.1}. It then deallocates the storage
+      occupied by the object designated by X {(and any coextensions)}. If
+      the storage pool is a user-defined object, then the storage is
+      deallocated by calling Deallocate, passing
+      access_to_variable_subtype_name'Storage_Pool as the Pool
+      parameter. Storage_Address is the value returned in the
+      Storage_Address parameter of the corresponding Allocate call.
+      Size_In_Storage_Elements and Alignment are the same values passed
+      to the corresponding Allocate call. There is one exception: if the
+      object being freed contains tasks, the object might not be
+      deallocated.
+
+   After Free(X), the object designated by X, and any subcomponents {(and
+   coextensions)} thereof, no longer exist; their storage can be reused
+   for other purposes.
+
+Delete 13.11.2(17.1/2).
+
 !discussion
 
 Our intent is to define the checks needed when an object with
@@ -485,6 +573,13 @@
 object with the access discriminant. This should be true whether
 the enclosing object is limited or non-limited.
 
+We have defined a new term, "coextension," to describe an
+object created by an allocator of an anonymous type that is
+being used to initialize an access discriminant of an "outer" object.
+An object and all its coextensions are allocated, initialized,
+finalized, and freed at the same point, as though the coextensions
+are components of the object.
+
 For a limited function return, the caller has to control where the
 return object is built. If the result subtype is unconstrained, while
 the call is being used to initialize a constrained object, including a
@@ -1014,7 +1109,124 @@
 
 !appendix
 
+!topic Accessibility level--contradiction?
+!reference RM05 3.10.2, 7.6.1
+!from Adam Beneschan 05-02-09
+!discussion
+
+I'm trying to understand how accessibility levels work with the new
+generalized anonymous access type stuff, and I'm running into some
+difficulties.  If my understanding of the RM is correct (a dubious
+assumption), it appears that the RM is saying something
+self-contradictory.
+
+Consider this example:
+
+   procedure P1 is
+
+      type Rec is record
+         C1 : access Integer;
+      end record;
+
+   begin...end P1;
+
+As I understand it, the elaboration of Rec is now considered to be a
+master, which has an accessibility level.  The type Rec also has an
+accessibility level (3.10.2(7)).  Of course, the execution of P1 is a
+master that has an accessibility level.  I'll denote these as
+Level(Elaboration-of-Rec), Level(Rec), and Level(P1), and use ">" to
+mean "deeper than".
+
+According to 3.10.2(7), an entity created by a declaration has the
+same accessibility level as the innermost enclosing master other than
+the declaration itself.  The type Rec is an entity.  It seems clear
+that the innermost enclosing master for this type declaration is the
+execution of P1.  Thus, Level(Rec) = Level(P1).
+
+3.10.2(12/2) says, "The accessibility level of the anonymous access
+type of a component is that of the master that elaborated its
+access_definition. This is the same as the level of the type whose
+definition encloses the access_definition except in the case of an
+access discriminant....."  Thus, the level of the anonymous access
+type "access Integer" is that of the master that elaborated this
+access definition.  If we follow 3.8(16-17), we find that the
+elaboration of Rec, which is a master, contains the elaboration of the
+record_definition, which contains the elaboration of the
+component_list, which contains the elaboration of the component_items
+(including component_declarations), which contain the elaboration of
+the component_definition, which is the access_definition in this case.
+Thus, the master that elaborated the access definition is the
+elaboration of Rec.  This means that, according to this paragraph, the
+accessibility level of the elaboration of this master,
+i.e. Level(Elaboration-of-Rec), is the same as the level of the type
+whose definition encloses the access definition, i.e. Level(Rec).
+[And the level of the anonymous access type is the same as both.]
+Thus, we have Level(Elaboration-of-Rec) = Level(Rec).
+
+Since we already established that Level(Rec) = Level(P1), this means
+Level(Elaboration-of-Rec) = Level(P1).
+
+3.10.2(6) says that the accessibility level of a master is deeper than
+that of each dynamically enclosing master.  Since the execution of P1
+dynamically encloses the elaboration of Rec, which is a master, we
+therefore have Level(Elaboration-of-Rec) > Level(P1).
+
+Something's wrong.
+
+*************************************************************
+
 From: Tucker Taft
+Sent: Wednesday, February  9, 2005  7:54 PM
+
+I think you are right.  3.10.2(7/2) says the following:
+
+    An entity or view created by a declaration has the same
+    accessibility level as the innermost enclosing master other
+    than the declaration itself except in the cases of renaming
+    and derived access types described below. A parameter of a
+    master has the same accessibility level as the master.
+
+and 7.6.1(3/2) says:
+
+    ... a master: the execution of a body other than a package_body;
+    the elaboration of a declaration other than the declaration of a
+    package; the execution of an accept_statement, a block_statement,
+    or a simple_statement; or the evaluation of an expression or range
+    that is not part of an enclosing expression, range, or
+    simple_statement.
+
+Although "access_definition" is not a declaration,
+"component_declaration" and "type_declaration" are
+both declarations, and we really only want one
+level there.  So 7.6.1 should probably exempt type
+declarations as well as package declarations from
+being masters.  I think that would solve the problem
+you identify.  Like package declarations, type
+declarations are essentially "see-through."  Of course
+entities created as part of the creation of an *object* of
+the type are another matter, and those are clearly related
+to the accessibility of the object, not the
+type declaration.
+
+> Consider this example:
+>
+>    procedure P1 is
+>
+>       type Rec is record
+>          C1 : access Integer;
+>       end record;
+>
+>    begin...end P1;
+ > ...
+
+If we eliminate "Rec" as a master, then the master
+of the anonymous access type created by the
+elaboration of "C1" is now P1, rather than Rec.
+Which is what we want.
+
+*************************************************************
+
+From: Tucker Taft
 Sent: Thursday, February 17, 2005  3:17 AM
 
 Our last discussion about access discriminants
@@ -1060,3 +1272,4 @@
 So those who were concerned can breathe easier. ;-)
 
 *************************************************************
+

Questions? Ask the ACAA Technical Agent