CVS difference for ais/ai-00216.txt

Differences between 1.10 and version 1.11
Log of other versions for file ais/ai-00216.txt

--- ais/ai-00216.txt	2002/12/04 23:43:37	1.10
+++ ais/ai-00216.txt	2003/02/01 04:40:33	1.11
@@ -1,4 +1,4 @@
-!standard B.03.03      (00)                         02-12-02  AI95-00216/09
+!standard B.03.03      (00)                         03-01-30  AI95-00216/10
 !standard B.03         (60.2)
 !class amendment 99-03-23
 !status work item 02-11-06
@@ -193,11 +193,12 @@
 Program_Error is raised in the following cases:
 
     Evaluation of the predefined equality operator for an unchecked union type
-    if either of the operands lacks inferable discriminants. [This includes the
-    case where the equality operator is invoked implicitly by the equality
-    operator for an enclosing composite type - if the unchecked union
-    component subtype is unconstrained, Program_Error is raised].
+    if either of the operands lacks inferable discriminants.
 
+    Evaluation of the predefined equality operator for a type which has
+    a subcomponent of an unchecked union type whose nominal subtype is
+    unconstrained.
+
     Evaluation of a membership test if the subtype_mark denotes a constrained
     unchecked union subtype and the expression lacks inferable discriminants.
 
@@ -212,6 +213,31 @@
     of an unchecked union type if the type lacks default discriminant values.
 
 
+              Implementation Permissions
+
+An implementation may require that pragma Controlled is specified for the type
+of an access subcomponent of an Unchecked_Union type.
+
+Notes
+
+The use of an unchecked union to obtain the effect of an
+unchecked conversion results in erroneous execution (see 11.5).
+Execution of the following example is erroneous:
+
+   type T (Flag : Boolean := False) is
+       record
+           case Flag is
+               when False =>
+                   F1 : Integer := 0;
+               when True =>
+                   F2 : Integer := 1;
+           end case;
+       end record;
+   pragma Unchecked_Union (T);
+
+   X : T;
+   Y : Integer := X.F2; -- erroneous
+
 !example
 
 Given the C type:
@@ -363,12 +389,13 @@
 
 Program_Error is raised in the following cases:
 
-@xbullet<Evaluation of the predefined equality operator for an unchecked union
-type if either of the operands lacks inferable discriminants. This includes
-the case where the equality operator is invoked implicitly by the equality
-operator for an enclosing composite type - if the unchecked union component
-subtype is unconstrained, Program_Error is raised.>
+@xbullet<Evaluation of the predefined equality operator for an unchecked union type
+if either of the operands lacks inferable discriminants.>
 
+@xbullet<Evaluation of the predefined equality operator for a type which has
+a subcomponent of an unchecked union type whose nominal subtype is
+unconstrained. >
+
 @xbullet<Evaluation of a membership test if the @fa<subtype_mark> denotes a
 constrained unchecked union subtype and the expression lacks inferable
 discriminants.>
@@ -384,7 +411,31 @@
 attribute of an unchecked union type if the type lacks default discriminant
 values.>
 
+@i<@s8<Implementation Permissions>>
+
+An implementation may require that @fa<pragma> Controlled is specified for the
+type of an access subcomponent of an Unchecked_Union type.
 
+Notes
+
+The use of an unchecked union to obtain the effect of an
+unchecked conversion results in erroneous execution (see 11.5).
+Execution of the following example is erroneous:
+
+@xcode<@b<type> T (Flag : Boolean := False) @b<is>
+   @b<record>
+       @b<case> Flag @b<is>
+           @b<when> False =>
+               F1 : Integer := 0;
+           @b<when> True =>
+               F2 : Integer := 1;
+       @b<end case>;
+   @b<end record>;
+@b<pragma> Unchecked_Union (T);
+
+X : T;
+Y : Integer := X.F2; -- @i<erroneous>>
+
 !appendix
 
 Randy Brukardt  99-03-29
@@ -2665,6 +2716,153 @@
 erroneousness.
 
 ...
+
+*************************************************************
+
+From: Steve Baird
+Sent: Tuesday, January 28, 2003 at 12:04 PM
+
+Pascal Leroy said:
+>  AI 216: the recent discussion demonstrated that there are a number of
+>  significant problems with the AI as written; it goes back to the original
+>  author (Steve B., as I recall) for update.
+
+This is my attempt to update the wording of AI-216 to reflect these issues.
+
+  -- Steve
+
+--------
+
+1) In the list of constructs which raise Program_Error in B.3.3's
+  "Dynamic Semantics" section, replace
+
+     Evaluation of the predefined equality operator for an unchecked union type
+     if either of the operands lacks inferable discriminants. [This includes the
+     case where the equality operator is invoked implicitly by the equality
+     operator for an enclosing composite type - if the unchecked union
+     component subtype is unconstrained, Program_Error is raised].
+
+   with
+
+     Evaluation of the predefined equality operator for an unchecked union type
+     if either of the operands lacks inferable discriminants.
+
+     Evaluation of the predefined equality operator for a type which has
+     a subcomponent of an unchecked union type whose nominal subtype is
+     unconstrained.
+
+2) At the end of the "Static Semantics" section of B.3.3 add:
+
+   Notes
+
+   The use of an unchecked union to obtain the effect of an
+   unchecked conversion results in erroneous execution (see 11.5).
+   Execution of the following example is erroneous:
+
+       type T (Flag : Boolean := False) is
+           record
+               case Flag is
+                   when False =>
+                       F1 : Integer := 0;
+                   when True =>
+                       F2 : Integer := 1;
+               end case;
+           end record;
+       pragma Unchecked_Union (T);
+
+       X : T;
+       Y : Integer := X.F2; -- erroneous
+
+
+
+3) At the end of B.3.3, add:
+
+                Implementation Permissions
+
+     An implementation may require that the type of an access subcomponent
+     of an Unchecked_Union type must be subject to a Controlled pragma.
+
+--------
+
+Discussion:
+
+1) I agree with Bob Duff's proposal regarding equality comparisons
+   and the circumstances under which Program_Error is raised.
+   Bob - speak up if this doesn't implement your proposal.
+
+2) Robert Eachus suggested adding rules along the lines of:
+       For an Unchecked_Union, it is the programmmer's
+       responsibility to ensure that any read or write
+       of the object references a valid value for the
+       type of the value, otherwise program execution is erroneous.
+   and also
+       It is erroneous to perform any operation (in C
+       or Ada) that would have failed a discriminant
+       check had the discriminant been present at runtime.
+
+   I generally agree with both of these statements, but they are already
+   implied by 11.5(26) and the rule that Discriminant_Check is suppressed
+   for an Unchecked_Union type. Therefore, I only added a note.
+
+   The existing rules do not cover the case of an Unchecked_Union object which
+   is initialized in C and then (mis)read in Ada, but this
+   is just one instance of the much larger problem of non-Ada code
+   breaking Ada's rules. Addressing just this one particular instance
+   of the problem does not seem like a good idea. What is really needed
+   is a very general clause in Annex B something like
+
+       If a use of an entity defined in a foreign language
+       results in violation of any property that is guaranteed
+       by the language or of any invariant that is maintained
+       by the implementation, then program execution is erroneous.
+
+   , but that is outside of the scope of this AI.
+
+3) Is there any need to allow the optional "no garbage-collected
+   access subcomponents of unchecked union types" restriction to be
+   implemented as a post-compilation rule?
+
+*************************************************************
+
+From: Randy Brukardt
+Sent: Thursday, January 30, 2003 at 6:44 PM
+
+Minor nits:
+> 2) At the end of the "Static Semantics" section of B.3.3 add:
+>   Notes
+>   ...
+
+Notes in the RM can only go at the end of a section, not in the middle. I
+presume this is RM note (it seems it should be to me), so I've moved it to
+the appropriate location.
+
+>3) At the end of B.3.3, add:
+>                Implementation Permissions
+>
+>     An implementation may require that the type of an access subcomponent
+>     of an Unchecked_Union type must be subject to a Controlled pragma.
+
+RM-speak seems to be "pragma Controlled" rather than "Controlled pragma".
+And "subject" is a word which is hardly ever used in the RM (I only found 12
+occurrences in the AARM).
+
+So I think this would be better if it said something like:
+
+An implementation may require that pragma Controlled is specified for the
+type of an access subcomponent of an Unchecked_Union type.
+
+>The existing rules do not cover the case of an Unchecked_Union object which
+>is initialized in C and then (mis)read in Ada, but this
+>is just one instance of the much larger problem of non-Ada code
+>breaking Ada's rules. Addressing just this one particular instance
+>of the problem does not seem like a good idea. What is really needed
+>is a very general clause in Annex B something like ...
+
+We discussed this in October, and I opened AI-320 to cover that, based on
+the solution discussed at the meeting and the existing wording in the
+Standard. So, you are completely correct when you say:
+
+>  but that is outside of the scope of this AI.
 
 *************************************************************
 

Questions? Ask the ACAA Technical Agent