CVS difference for ai05s/ai05-0008-1.txt
--- ai05s/ai05-0008-1.txt 2006/03/23 03:30:57 1.2
+++ ai05s/ai05-0008-1.txt 2006/10/10 00:52:43 1.3
@@ -1,5 +1,7 @@
-!standard 3.10.2(26/2) 06-03-18 AI05-0008-1/02
+!standard 3.3(23) 06-09-29 AI05-0008-1/03
+!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 work item 06-03-17
@@ -63,11 +65,41 @@
an access type that might designate an object that is constrained by its initial
value.
-Redo the wording of 3.10.2(26/2) and 8.5.1(5/2) to make it clear that it must be
-certain that the object is constrained before these operations are allowed.
+Define the term "known to be constrained" and redo the wording of 3.10.2(26/2) and
+8.5.1(5/2) to require that an object must be "known to be constrained" before
+components that depend on discriminants may be either renamed or used as the prefix
+of an Access attribute.
+
+Specify that passing a discriminated object as an actual parameter where the nominal
+subtype of the corresponding formal parameter is constrained and then modifying a
+discriminant of the actual before the call has completed results in erroneous execution.
!wording
+Add after 3.3(23):
+
+A composite object is "known to be constrained" if:
+
+ - its nominal subtype is constrained; 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
+ - 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.
+
+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
@@ -77,31 +109,10 @@
with the following:
- The view shall not be a subcomponent that depends on discriminants
- of an enclosing composite object (view) C whose nominal subtype is
- unconstrained, unless C is known to be constrained by its initial value,
- as follows:
-
- * the subtype of C is indefinite;
-
- * C is part of a stand-alone constant (including a generic formal
- object of mode IN);
-
- * C is a stand-alone variable constrained by its initial value; or
-
- * C is a dereference of a pool-specific access type, and there is
- no partial view of the type of C that is constrained.
-
- AARM NOTE: We disallow dereferences of general access types because
- they might denote stand-alone aliased unconstrained variables.
-
- 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. For the
- purposes of determining within a generic body whether C is known to be
- constrained by its initial value, 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.
+ 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.
Modify 4.1(9) as follows:
@@ -116,18 +127,27 @@
AARM NOTE (added after the Ada 95 ones):
The last sentence is different from Ada 95; it is necessary because general
- access types can designated unconstrained objects in Ada 2005 (that was not
+ access types can designate unconstrained objects in Ada 2005 (that was not
possible in Ada 95). Thus, the rules that had this effect in Ada 95 (the object
being constrained by its initial value) don't work in Ada 2005 and we have to
say this explicitly.
The "except" part of the last sentence prevents privacy "breaking", so that
if a private type has discriminants only in the full view, they don't
- interfere with freely interassigning values between objects the type, even
- when the objects live in the heap.
+ 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.
+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).
+
Replace 8.5.1(5/2):
The renamed entity shall not be a subcomponent that depends on discriminants
@@ -143,40 +163,67 @@
with the following:
- The renamed entity shall not be a subcomponent that depends on discriminants
- of an enclosing composite object (view) C whose nominal subtype is
- unconstrained, unless C is known to be constrained by its initial value,
- as follows:
-
- * the subtype of C is indefinite;
-
- * C is part of a stand-alone constant (including a generic formal
- object of mode IN);
-
- * C is a stand-alone variable constrained by its initial value; or
-
- * C is a dereference of a pool-specific access type, and there is
- no partial view of the type of C that is constrained.
-
- AARM NOTE: We disallow dereferences of general access types because
- they might denote stand-alone aliased unconstrained variables.
-
- A slice of an array shall not be renamed if these rules disallow 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.
- For the purposes of determining within a generic body whether C is known to
- be constrained by its initial value, 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.
+ 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 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.
+
+[Note: The last sentence of the original paragraph is redundant with the new text in
+3.3, and thus is removed.]
+
+!example
+
+The need for the 6.4.1 change is illustrated by the following example:
+
+ declare
+ type Component is tagged null record;
+
+ type By_Reference (D : Boolean := False) is
+ record
+ C : Component;
+ end record;
+
+ subtype Constrained is By_Reference (False);
+
+ Global_To_P : By_Reference;
+
+ procedure P (X : Constrained) is
+ begin
+ Global_To_P := (D => True, C => <>); -- erroneous
+ pragma Assert (X in Constrained); -- ok to generate no code for pragma
+ end P;
+ begin
+ P (Global_To_P);
+ end;
+
+This was intended to be covered by 3.7.4(4), but that rule doesn't apply to
+an IN parameter passed by reference as the parameter itself is not a name
+denoting a subcomponent that depends on discriminants (the actual parameter
+might be, but the formal parameter is not a subcomponent).
!discussion
-3.10.2(26/2) and 8.5.1(5/2) are not really wrong, because they both say the operation
-is illegal "unless the variable is constrained by its initial value". That's not
-true here; we only know that it *might* be constrained, and that is not enough as
-legality rules require certainty. But it is best to improve the wording so this
-is clear.
+The word "object" is used instead of "variable" in the new wording for 3.10.2(26/2)
+and 8.5.2(5/2). This excludes constants which are not known to be constrained, such
+as access-to-constant dereferences. The definition of "known to be constrained" includes
+the case of an in-mode subprogram parameter with an unconstrained nominal subtype.
+This opens the door slightly for misuse of the Unchecked_Access attribute, but it is no
+worse than what can be done with a formal parameter whose nominal subtype is constrained.
+In both cases, the problem would be the conversion of a reference to a subcomponent of a
+parameter that depends on discriminants into a value of a global access type which outlives
+the subprogram call. After the call has terminated, the enclosing object is modified so
+that the referenced subcomponent no longer exists. The existing wording of 13.10(1) seems
+sufficiently general to handle this case.
+
+In an effort to keep the wording as simple as possible, the definition of
+"known to be constrained" does not mention some cases (e.g., view conversions,
+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)).
!ACATS test
Questions? Ask the ACAA Technical Agent