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

Differences between 1.3 and version 1.4
Log of other versions for file ai05s/ai05-0008-1.txt

--- ai05s/ai05-0008-1.txt	2006/10/10 00:52:43	1.3
+++ ai05s/ai05-0008-1.txt	2006/12/16 03:13:16	1.4
@@ -1,9 +1,10 @@
-!standard 3.3(23)                                    06-09-29    AI05-0008-1/03
+!standard 3.3(23)                                    06-12-13    AI05-0008-1/04
 !standard 3.10.2(26/2)
 !standard 4.1(9)
 !standard 6.4.1(17)
 !standard 8.5.1(5/2)
 !class binding interpretation 06-03-17
+!status ARG Approved  9-0-3  06-11-18
 !status work item 06-03-17
 !status received 05-10-13
 !priority High
@@ -78,28 +79,29 @@
 
 Add after 3.3(23):
 
-A composite object is "known to be constrained" if:
+A view of a composite object is "known to be constrained" if:
 
- - its nominal subtype is constrained; or
+ - its nominal subtype is constrained, and is not an untagged partial view; or
  - its nominal subtype is indefinite; or
- - its type is a protected type, a task type, or a type that has
-   the reserved word limited in its full definition; or
+ - its type is a protected type, a task type, or an explicitly limited record type; or
  - it is part of a stand-alone constant (including a generic formal object of mode in); or
  - it is part of a formal parameter of mode in; or
  - it is part of the object denoted by a function_call or aggregate; or
  - it is part of a constant return object of an extended_return_statement; or
  - it is a dereference of a pool-specific access type, and there is no partial view of
    its type that is constrained.
-   
+
 AARM NOTE: We do not include dereferences of general access types because they might denote
 stand-alone aliased unconstrained variables. That's true even for access-to-constant types.
-
+END AARM Note.
+   
 For the purposes of determining within a generic body whether an object is known to be
 constrained, a subtype is not considered indefinite if it is a descendant of an untagged
 generic formal derived type, nor is an access type considered pool-specific if it is a
 descendant of a formal access type.
 
 
+
 Replace 3.10.2(26/2):
 
     The view shall not be a subcomponent that depends on discriminants
@@ -137,16 +139,16 @@
     interfere with freely interassigning values between objects of the type,
     even when the objects live in the heap.
 
-  Retain the AARM note 4.1(9.d/2) from Draft 16 of the Ada 2005 AARM.
+  Retain the AARM note 4.1(9.d/2) from the Ada 2005 AARM.
 
 Add after 6.4.1(17):
 
                         Erroneous Execution
         
-If the nominal subtype of a formal parameter with discriminants is constrained,
-then the execution of the call is erroneous if the value of any of the
-discriminants of the actual is changed while the formal parameter exists
-(i.e., before leaving the corresponding callable construct).
+If the nominal subtype of a formal parameter with discriminants is constrained or
+indefinite, and the parameter is passed by reference, then the execution of the call is
+erroneous if the value of any discriminant of the actual is changed while the
+formal parameter exists (that is, before leaving the corresponding callable construct).
 
 Replace 8.5.1(5/2):
 
@@ -171,8 +173,10 @@
     a generic unit.
 
 [Note: The last sentence of the original paragraph is redundant with the new text in
-3.3, and thus is removed.]
+3.3, and thus is removed.
 
+Editor's note: I don't believe the above.]
+
 !example
 
 The need for the 6.4.1 change is illustrated by the following example:
@@ -203,6 +207,40 @@
 denoting a subcomponent that depends on discriminants (the actual parameter
 might be, but the formal parameter is not a subcomponent).
 
+The new wording for 6.4.1 needs to include "indefinite" so that problems with
+untagged derived types are covered. Consider:
+
+    package P is
+       pragma Elaborate_Body;
+       type T (D : Integer) is private;
+    private
+       type T (D : Integer) is tagged
+          record
+             C : String (1 .. D);
+          end record;
+    end P;
+ 
+    with P;
+    package Q is
+       type NT (ND : Integer := 3) is new T (ND);
+       X : NT;
+       Y : NT (0);
+    end Q
+ 
+    with Q, Ada.Text_IO;
+    package body P is
+	procedure P2 (Z : in out T) is -- Assume pass-by-reference
+	   C_Ren : Character renames Z.C(2); -- OK, Z is indefinite.
+	begin
+	   Q.X := Q.Y; -- Erroneous.
+           Ada.Text_IO.Put (C_Ren); -- Doesn't exist anymore.
+	end P2;
+	
+    begin
+       P2 (T(Q.X)); -- OK.
+    end P;
+
+
 !discussion
 
 The word "object" is used instead of "variable" in the new wording for 3.10.2(26/2)
@@ -222,9 +260,111 @@
 the current instance of a type, implementation-defined attributes, objects of a
 generic formal discriminated private type) which are irrelevant in the two places
 where this term is used. Following this reasoning, the words "or aggregate"
-could be deleted from the definition (although echoing the wording of AI-0015
-seems nice) as well as the mention of "a task type," (which follows 3.10(9/2)).
+could be deleted from the definition (although echoing the wording of AI05-0015
+seems nice) as well as the mention of "a task type," (which follows 3.10(9/2)),
+and "and is not an untagged partial view" (which seems valuable to avoid confusion about
+uncovered cases).
+
+!corrigendum 3.3(23)
+
+@dinsa
+At the place where a view of an object is defined, a @i<nominal subtype> is
+associated with the view. The object's @i<actual subtype> (that is, its subtype)
+can be more restrictive than the nominal subtype of the view; it always is if
+the nominal subtype is an @i<indefinite subtype>. A subtype is an indefinite subtype
+if it is an unconstrained array subtype, or if it has unknown discriminants or
+unconstrained discriminants without defaults (see 3.7); otherwise the subtype is a
+definite subtype (all elementary subtypes are definite subtypes). A class-wide
+subtype is defined to have unknown discriminants, and is therefore an indefinite
+subtype. An indefinite subtype does not by itself provide enough information to
+create an object; an additional constraint or explicit initialization expression
+is necessary (see 3.3.1). A component cannot have an indefinite nominal subtype.
+@dinss
+A view of a composite object is @i<known to be constrained> if:
+
+@xbullet<its nominal subtype is constrained, and is not an untagged partial view; or>
+@xbullet<its nominal subtype is indefinite; or>
+@xbullet<its type is a protected type, a task type, or an explicitly limited record type; or>
+@xbullet<it is part of a stand-alone constant (including a generic formal object
+of mode @b<in>); or>
+@xbullet<it is part of a formal parameter of mode @b<in>; or>
+@xbullet<it is part of the object denoted by a @fa<function_call> or @fa<aggregate>; or>
+@xbullet<it is part of a constant return object of an @fa<extended_return_statement>; or
+@xbullet<it is a dereference of a pool-specific access type, and there is no partial
+view of its type that is constrained.>
+   
+For the purposes of determining within a generic body whether an object is known to be
+constrained, a subtype is not considered indefinite if it is a descendant of an untagged
+generic formal derived type, nor is an access type considered pool-specific if it is a
+descendant of a formal access type.
+
+!corrigendum 3.10.2(26/2)
+
+@drepl
+@xbullet<The view shall not be a subcomponent that depends on discriminants
+of a variable whose nominal subtype is unconstrained, unless this
+subtype is indefinite, or the variable is constrained by its initial value.>
+@dby
+@xbullet<The view shall not be a subcomponent that depends on discriminants of
+an object unless the object is known to be constrained. In addition to
+the places where Legality Rules normally apply, this rule applies also
+in the private part of an instance of a generic unit.>
+
+!corrigendum 4.1(9)
+
+@drepl
+If the type of the @fa<name> in a dereference is some access-to-object type @i<T>,
+then the dereference denotes a view of an object, the nominal subtype of the
+view being the designated subtype of @i<T>. 
+@dby
+If the type of the @fa<name> in a dereference is some access-to-object type @i<T>,
+then the dereference denotes a view of an object, the nominal subtype of the
+view being the designated subtype of @i<T>. If the designated subtype has
+unconstrained discriminants, the (actual) subtype of the view is constrained
+by the values of the discriminants of the designated object, except when
+there is a partial view of the type of the designated subtype that does not
+have discriminants, in which case the dereference is not constrained by its
+discriminant values.
+
+!corrigendum 6.4.1(17)
+
+@dinsa
+After normal completion and leaving of a subprogram, for each @b<in out> or
+@b<out> parameter that is passed by copy, the value of the formal parameter is
+converted to the subtype of the variable given as the actual parameter and
+assigned to it. These conversions and assignments occur in an arbitrary order. 
+@dinst
+@s9<@i<Erroneous Execution>>
+        
+If the nominal subtype of a formal parameter with discriminants is constrained
+or indefinite, and the parameter is passed by reference, then the execution of
+the call is erroneous if the value of any discriminant of the actual is changed
+while the formal parameter exists (that is, before leaving the corresponding
+callable construct).
+
+!corrigendum 8.5.1(5/2)
+
+@drepl
+The renamed entity shall not be a subcomponent that depends on discriminants
+of a variable whose nominal subtype is unconstrained, unless this subtype is
+indefinite, or the variable is constrained by its initial value. A @fa<slice>
+of an array shall not be renamed if this restriction disallows renaming of the
+array. In addition to the places where Legality Rules normally apply, these
+rules apply also in the private part of an instance of a generic unit. These
+rules also apply for a renaming that appears in the body of a generic unit,
+with the additional requirement that even if the nominal subtype of the
+variable is indefinite, its type shall not be a descendant of an untagged
+generic formal derived type.
+@dby
+The renamed entity shall not be a subcomponent that depends on discriminants of
+an object whose nominal subtype is unconstrained unless the object is known
+to be constrained. A @fa<slice> of an array shall not be renamed if this restriction
+disallows renaming of the array. In addition to the places where Legality Rules
+normally apply, these rules apply also in the private part of an instance of
+a generic unit.
+
 
+
 !ACATS test
 
 An ACATS B-Test and an ACATS C-Test should be created to test these cases.
@@ -1196,5 +1336,79 @@
 > > And for 8.5.1(5/2):
 
 Same changes here.
+
+****************************************************************
+
+Summary of private e-mail of December 13-14, 2006
+Involving Randy Brukardt, Pascal Leroy, and Stephen Baird.
+
+We accidentally uncovered a new problem with the AI. Here's the sequence of events:
+
+Randy thought a rule was missing from the AI, and asked Pascal and Steve
+about it, appending an example from AI95-184 showing the need for the rule.
+Unfortunately, he appended the *wrong* example from that AI (there are two),
+commenting that it showed that view conversions might actually matter in the
+3.3(23) rules.
+
+Pascal replied that this is handled properly by the language, and there isn't
+any view conversion in the example, but that there was a way to get the
+effect of a view conversion for that example.
+
+Randy ignored most of Pascal's note and sent the correct example (which was
+about generics).
+
+Steve pointed out that the needed wording is in fact in the AI (although
+Randy missed it completely). He then went on to comment that Pascal's example
+is in fact a real problem, and suggested a solution based on it being part
+of the second example Randy sent (rather than the first).
+
+Randy responded extensively to Steve's note before realizing that Pascal's
+example was meant to be part of the *first* example sent. And it wasn't quite
+legal, as it was missing a conversion: in fact a view conversion, the one
+that prompted the example in the first place.
+
+The net effect is an amazingly confused thread of e-mail. So just a summary of
+what actually matters is presented here.
+
+-------------------------------------------------------------------
+
+Consider the following example (based on AI95-184).
+
+    package P is
+       pragma Elaborate_Body;
+       type T (D : Integer) is private;
+    private
+       type T (D : Integer) is tagged
+          record
+             C : String (1 .. D);
+          end record;
+    end P;
+ 
+    with P;
+    package Q is
+       type NT (ND : Integer := 3) is new T (ND);
+       X : NT;
+       Y : NT (0);
+    end Q
+ 
+    with Q, Ada.Text_IO;
+    package body P is
+	procedure P2 (Z : in out T) is -- Assume pass-by-reference
+	   C_Ren : Character renames Z.C(2);
+	begin
+	   Q.X := Q.Y;
+           Ada.Text_IO.Put (C_Ren); -- Ouch, C_Ren no longer exists.
+	end P2;
+	
+    begin
+        P2 (T(Q.X)); -- OK.
+    end P;
+
+Note that T(Q.X) is a view conversion in this context. If we're assuming
+pass-by-reference, then we have a situation very similar to the one for
+constrained parameters.
+
+Pascal suggested changing 6.4.1(17.1) to say "constrained or indefinite",
+so that the new rule would also apply to this case.
 
 ****************************************************************

Questions? Ask the ACAA Technical Agent