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

--- ai05s/ai05-0051-1.txt	2009/04/30 06:19:47	1.9
+++ ai05s/ai05-0051-1.txt	2009/06/02 01:57:20	1.10
@@ -1,4 +1,4 @@
-!standard 3.10.2(14/2)                              08-07-19    AI05-0051-1/07
+!standard 3.10.2(14/2)                              09-06-01    AI05-0051-1/08
 !standard 3.10.2(14.4/2)
 !standard 3.10.2(19/2)
 !standard 6.5(21/2)
@@ -36,6 +36,9 @@
 
 Should similar checks be performed for class-wide allocators? (Yes.)
 
+Should similar checks be performed for part of return objects
+that have access discriminants? (Yes.)
+
 Should compile-time checks analogous to the existing checks of
 4.8(5.2/2) and 6.5(5.6/2) also be performed? (Yes.)
 
@@ -182,11 +185,11 @@
 
 Modify 6.5(21/2) as follows:
 
-    If the [result subtype]{return object} of a function has one or more
-    [unconstrained] 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
+    If [the result subtype]{any part of the return object or coextension thereof}
+    of a function has one or more [unconstrained] 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, is not deeper than [that
     of the master that elaborated the function body] {the level of the
     return object as determined by the point of call (see 3.10.2)}. If
@@ -362,6 +365,43 @@
 Do we need to generalize the definition of "nominal subtype" so that it
 is defined for all expressions, not just names?
 
+---
+
+Similarly, we may need to make these checks for components or coextensions
+of the return object. Consider:
+
+   procedure Defaulted_Access_Discrim is
+    X : aliased Integer;
+
+    type Discriminated (D : access Integer := X'Access) is
+       limited null record;
+
+    type Undiscriminated is
+       limited record
+          Comp : Discriminated;
+       end record;
+
+    type Ref is access Undiscriminated;
+    Ptr : Ref;
+
+    procedure P is
+       Y : aliased Integer := 0;
+
+       function F return Undiscriminated is
+       begin
+          return Z : Undiscriminated := (Comp => (D => Y'Access));
+       end F;
+
+    begin
+       Ptr := new Undiscriminated'(F);
+    end P;
+  begin
+    P;
+    -- if we reach this point, Ptr.all.Comp.D is dangling
+  end Defaulted_Access_Discrim;
+
+6.5(21) needs to cover this case as well.
+
 ------
 
 Discussion related to dispatching calls reaching primitive functions
@@ -2975,5 +3015,100 @@
 shouldn't change the behavior of the program.
 
 Do you agree?
+
+*****************************************************************
+
+From: Steve Baird
+Sent: Thursday, April  9, 2009  11:40 AM
+
+Consider the following example:
+
+   procedure Defaulted_Access_Discrim is
+    X : aliased Integer;
+
+    type Discriminated (D : access Integer := X'Access) is
+       limited null record;
+
+    type Undiscriminated is
+       limited record
+          Comp : Discriminated;
+       end record;
+
+    type Ref is access Undiscriminated;
+    Ptr : Ref;
+
+    procedure P is
+       Y : aliased Integer := 0;
+
+       function F return Undiscriminated is
+       begin
+          return Z : Undiscriminated := (Comp => (D => Y'Access));
+       end F;
+
+    begin
+       Ptr := new Undiscriminated'(F);
+    end P;
+  begin
+    P;
+    -- if we reach this point, Ptr.all.Comp.D is dangling
+  end Defaulted_Access_Discrim;
+
+What language rule (static or dynamic) is supposed to prevent the generation of
+a dangling reference in this case?
+
+Is the runtime check of 3.10.2(29) supposed to catch this?
+
+I don't think so; the "hand off" described in 3.10.2(10.1/2) has not taken
+place yet at the time of the check and so the accessibility level of Z is
+deeper than that of Y.
+
+It's not clear (to me) whether 3.10.2(12/2) applies here - is a subcomponent of
+a (nondiscriminant) component considered to be "in the expression ... of a return
+statement"? - but the runtime check would not fail even if it does apply.
+
+*****************************************************************
+
+From: Tucker Taft
+Sent: Thursday, April  9, 2009  2:47 PM
+
+This looks like another job for good old AI05-51.  Currently it proposes
+for 6.5(21/2):
+
+   If the [result subtype]{return object} of a function
+   has one or more [unconstrained] 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, is not deeper
+   than [that of the master that elaborated the function body]
+   {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.
+
+I believe this may need to say something like:
+
+    If any part or coextension of the return object of a
+    function has one or more access discriminants
+    whose value is not determined by the result subtype of
+    the function, ...
+
+I'm surprised it didn't already cover coextensions, but it clearly also needs
+to cover "parts" based on your example.
+
+I think the above change would solve your problem.
+
+*****************************************************************
+
+From: Steve Baird
+Sent: Thursday, April  9, 2009  2:47 PM
+
+The general approach sounds fine (although an AARM note explaining that this
+only imposes overhead in some very obscure cases might be worth including).
+
+Do we need a generalization of the term "part" that includes coextensions?
+Note that the phrase "part or coextension of a return object" does not include
+a subcomponent of a coextension. I understand that you were not proposing formal
+wording here.
 
 *****************************************************************