CVS difference for ai05s/ai05-0234-1.txt

Differences between 1.9 and version 1.10
Log of other versions for file ai05s/ai05-0234-1.txt

--- ai05s/ai05-0234-1.txt	2011/03/17 05:46:16	1.9
+++ ai05s/ai05-0234-1.txt	2011/03/17 05:54:21	1.10
@@ -1,4 +1,4 @@
-!standard  6.5(21/3)                               11-03-16    AI05-0234-1/04
+!standard  6.5(21/3)                               11-03-17    AI05-0234-1/05
 !class binding interpretation 10-11-15
 !status work item 10-11-15
 !status received 10-10-31
@@ -57,6 +57,32 @@
           & Integer'Image (Extension (Ptr.all).Discrim.all));
    end Cw_Alloc;
 
+
+Another case not addressed is when there is an unconstrained subcomponent
+with a defaulted access discriminant:
+
+    X : aliased Integer;
+
+    type Subcomponent_Type (Discrim : access Integer := X'Access)
+      is limited null record;
+
+    type Component_Type is record S : Subcomponent_Type; end record;
+
+    type Undiscriminated is record
+      Fld : Component_Type;
+    end record;
+
+    function F return Undiscriminated is
+        Local : aliased Integer;
+    begin
+        return X : Undiscriminated
+          := (Fld => (S => (Discrim => Local'Access))) do
+
+          Foo;
+        end return;
+        -- should raise Program_Error after calling Foo.
+    end F;
+
 Are the access discriminant accessibility checks associated with allocators and
 function returns performed even in the case where the existence of those
 discriminants is not known statically at the point of the check? (Yes.)
@@ -75,7 +101,7 @@
   function call is that of the innermost master that evaluates the aggregate or
   function.
 
-revising it to only describe the aggregate case as follows:
+revising it to only address the aggregate case, as follows:
 
   The accessibility level of an aggregate that is used (in its entirety) to
   directly initialize part of an object is that of the object being initialized.
@@ -89,11 +115,12 @@
     the point of call" as follows:
 
     + If the result is used (in its entirety) to directly initialize part of an
-      object, the accessibility level is that of the object being initialized;
+      object, the accessibility level is that of the object being initialized.
+  ??? In the case where the initialized object is a coextension that becomes
+      a coextension of another object (see below), the accessibility level is
+      the level of the eventual object to which the coextension will be
+      transferred. ???
 
-    [Author's note: I believe that a bullet may be needed here for coextensions,
-     but this version doesn't yet address that.]
-
     + If the result is of an anonymous access type and is the operand of an
       explicit conversion, the accessibility level is that of the target type
       of the conversion;
@@ -112,14 +139,12 @@
   [AARM] Ramification: The accessibility level of a function result object
   in the case where building in place is optional and the implementation elects
   not to build in place is the same as if the implementation had decided to
-  build in place. In other words, the effect in terms of masters, lifetimes,
-  and accessibility is transparent to the program. Note that this does not imply
-  that a level has to be passed on calls in cases where the implementation
-  does not build in place, just that the semantics are equivalent.]
+  build in place. In other words, the effect of this choice in terms of masters,
+  lifetimes, and accessibility is transparent to the program.
 
   [AARM] Implementation Note: There are several cases where the implementation
-  has to pass in the accessibility level of the result object on a call, to
-  support later rules where the accessibility level is said to be determined
+  may have to pass in the accessibility level of the result object on a call,
+  to support later rules where the accessibility level is said to be determined
   by the point of call:
 
     * when the function result may have a part with access discriminants;
@@ -136,7 +161,7 @@
   must also have a level parameter.
 
 
-Add a new paragraph after 3.10.2(12.1/2) to cover the case of an access
+Add a paragraph after 3.10.2(12.1/2) to cover the case of an access
 discriminant whose value is defined by default:
 
     + If the value of the access discriminant is determined by a default
@@ -184,43 +209,27 @@
      object is not deeper than that [of the master of the function result]
      {determined by the point of call (see 3.10.2)}.
 
-   [Author's question: Doesn't the immediately following AARM paragraph
-   6.4.1(15.a.1/3) need to be changed to reflect this?  It seems to be
-   implying that levels don't need to be passed for aliased parameters,
-   but that's no longer true, because we're passing them for the
-   "determined by the point of call" stuff. Perhaps other AARM paragraphs
-   also need changes (maybe in 7.6.1(13.*)?]
-
-
-[Author's question: Does 6.5(8/3) need to be modified somehow to account
-for "determined by the point of call"?  In version 1.6 of AI05-234, Steve
-Baird made a change to this paragraph to say "ultimate master that elaborated
-the function body". I don't see why that's necessary, but I may well be
-missing something!]
-
-
 Modify 6.5(21/3) (as modified by AI05-0051-1) as follows:
 
-   If any part {of the specific type} of the return
-   object {of a function} (or coextension thereof) [of a function] has one or
-   more access discriminants whose value is not constrained by the result
-   subtype of the function, a check is made that the accessibility level of the
-   anonymous access type of each access discriminant, as determined by the
-   expression or the return_subtype_indication [of the function] {of the return
-   statement}, is not deeper than the level of the return object as determined
-   by the point of call (see 3.10.2). If this check fails, Program_Error is
-   raised.
-
-[Author's question: The part about "of the specific type" is a change
-proposed by Steve Baird to his original wording "(ignoring the value
-of bounds and discriminants)", but I'm not sure that this quite works
-in the class-wide case.  Do we need to add more wording to describe
-getting the type based on the tag in the class-wide case?  Note that
-the reason for this wording is to avoid the implementation having to
-determine whether such components actually exist in the object, such
-as when there are empty arrays and inactive variant-dependent components.]
+   If any part {of the specific type} of the return object {of a function} (or
+   coextension thereof) [of a function] has one or more access discriminants
+   whose value is not constrained by the result subtype of the function,
+   a check is made that the accessibility level of the anonymous access type
+   of each access discriminant, as determined by the expression or the
+   return_subtype_indication [of the function] {of the return statement},
+   is not deeper than the level of the return object as determined by the
+   point of call (see 3.10.2). If this check fails, Program_Error is raised.
+
+Add the following AARM implementation note after 6.5(21/3):
+
+   The reason for saying "any part of the specific type" is to simplify
+   implementation. In the case of class-wide result objects this allows
+   the testing of a simple flag in the tagged type descriptor that indicates
+   whether specific type has any parts with access discriminants. By basing
+   the test on the object's type rather than the object itself, we avoid
+   concerns about the whether subcomponents of arrays (which might be empty)
+   and in variant parts are present.
 
-
 Add a (massive) AARM note after 6.5(21/3):
 
    For a function with a class-wide result type, the access values that
@@ -277,9 +286,9 @@
       end record;
 
       function F return Undiscriminated is
-          Local : aliaed Integer;
+          Local : aliased Integer;
       begin
-          return X : Untagged := (Fld => (Discrim => Local'Access)) do
+          return X : Undiscriminated := (Fld => (Discrim => Local'Access)) do
             Foo;
           end return;
           -- raises Program_Error after calling Foo.
@@ -291,7 +300,7 @@
    check is needed, discriminant values and array bounds
    play no role in performing this check. That is, array components are
    assumed to have nonzero length and components declared
-   within variant parts are assumed to be present  Thus, the check
+   within variant parts are assumed to be present. Thus, the check
    may be implemented simply by testing the aforementioned descriptor
    bit and conditionally raising Program_Error.
 
@@ -304,12 +313,12 @@
 shorter-lived than the eventual destination of the function result, as
 determined by the point of call).
 
-In the case where the designated type of an access type is classwide, say
+In the case where the designated type of an access type is class-wide, say
 T'Class, it needs to be made clear that this check is based on the tag of the
 allocated object. A check may be required even if, for example, T is
 undiscriminated.
 
-In the case where a function result type is classwide, a similar check is
+In the case where a function result type is class-wide, a similar check is
 needed. The problem is illustrated by the following two examples:
 
    procedure Cw_Alloc is
@@ -336,6 +345,10 @@
      ...
    end Cw_Alloc;
 
+Here is a similar case involving a class-wide function result. This case
+is properly handled by the wording changes of AI05-0051, but it serves
+as a useful example where the same kind of checking is needed.
+
    procedure Cw_Return is
      type Root is tagged null record;
      type Extension (Discrim : access Integer)
@@ -359,8 +372,8 @@
      ...
    end Cw_Return;
 
-In addition, these checks also need to be generalized to handle the case of a
-subcomponent which has defaulted access discriminant values, as in
+In addition, these checks are designed to handle the case of a
+subcomponent which has defaulted access discriminant values, as in:
 
     X : aliased Integer;
 
@@ -374,9 +387,9 @@
     end record;
 
     function F return Undiscriminated is
-        Local : aliaed Integer;
+        Local : aliased Integer;
     begin
-        return X : Untagged
+        return X : Undiscriminated
           := (Fld => (S => (Discrim => Local'Access))) do
 
           Foo;
@@ -384,6 +397,15 @@
         -- raises Program_Error after calling Foo.
     end F;
 
+The main set of wording changes in this AI is formalizing the definition
+in 3.10.2 of the term "determined by the point of call", which was already
+used in 3.10.2(10.1/2), and several additional uses were added by the changes
+of AI05-0051.  We also made changes to the check done for allocators to
+ensure that the check is done if any part of the object's subtype has
+an access discriminant, to check explicitly aliased parameters based on
+the level determined at the point of call, and to define the accessibility
+level of the access type associated with defaulted access discriminants.
+
 !example
 
 !ACATS Test
@@ -2248,7 +2270,54 @@
 ****************************************************************
 
 From: Gary Dismukes
-Sent: Wednesday, March 16, 2011  12:49 AM
+Sent: Wednesday, March 16, 2011  11:05 PM
+
+Here's the revision of AI05-234, with various questions in the preliminary
+version that I posted last night removed and/or resolved, plus minor updates
+to the !question and !discussion sections.
+
+[This is version /05 of the AI - Editor.]
+
+It would still be nice to get an answer to the side question I included
+in the preamble of my previous posting, but not essential to this AI:
+
+> BTW, sort of a side question I'd like an answer to that isn't included below
+> in the AI is about a paragraph in the !wording of AI05-51 that doesn't appear
+> to have made it into the online RM.  The paragraph defines the statically
+> deeper relationship for the case of an anonymous access result.  I'd like
+> to know if that's an oversight or was it decided at some point that it was
+> wrong or unneeded (but it looks like it was an oversight).
+>
+> In AI05-51 (both !wording and !corrigendum) it says:
+>
+>   Add after 3.10.2(19/2):
+>
+>   * For determining whether a level is statically deeper than the level of the
+>     anonymous access type of an access result of a function, when within a
+>     return statement that applies to the function, the level determined by the
+>     point of call is presumed to be the same as that of the level of the master
+>     that elaborated the function body.
+>
+> If this was supposed to be added, then it would probably make sense to
+> correct the oversight in AI05-234.
+
+****************************************************************
+
+From: Randy Brukardt
+Sent: Wednesday, March 16, 2011  11:37 PM
+
+Sorry, I was going to answer this earlier. Tucker noticed this when we were
+wording on AI05-0235-1, and the oversight was corrected in that AI. It's in the
+working draft of the RM, but of course you don't have that yet.
+
+And it really wasn't an oversight. What happened was that AI05-0142-4 originally
+combined some wording about explicitly aliased parameters with this bullet. Then
+someone "improved" that wording by eliminating the part about the access result
+of a function. Which of course led to it disappearing altogether. Since
+AI05-0142-4 included instructions that it's paragraph superseded this one, it
+got removed.
+
+In any case, you needn't worry about it.
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent