CVS difference for ais/ai-00167.txt

--- ais/ai-00167.txt	2003/03/04 04:56:21	1.7
+++ ais/ai-00167.txt	2003/05/24 00:51:33	1.8
@@ -1,4 +1,4 @@
-!standard 13.09.01 (12)                               03-02-09  AI95-00167/03
+!standard 13.09.01 (12)                               03-05-03  AI95-00167/04
 !class binding interpretation 98-03-18
 !status Amendment 200Y 03-02-19
 !status ARG Approved 6-2-0  03-02-09
@@ -10,8 +10,8 @@
 
 !summary
 
-It is not erroneous to assign the result of a call to Unchecked_Conversion or
-an imported function to an object and immediately test it with 'Valid.
+Assigning the result of a call on Unchecked_Conversion or an imported function
+to an object and immediately testing it with 'Valid is not erroneous.
 
 !question
 
@@ -39,11 +39,11 @@
 A call to an imported function or an instance of Unchecked_Conversion is
 erroneous if the result is scalar, the result object has an invalid
 representation, and the result is used other than as the expression of
-an assignment_statement or an object declaration, or as the prefix of a "Valid"
+an assignment_statement or an object_declaration, or as the prefix of a Valid
 attribute. If such a result object is used as the source of an
 assignment, and the assigned value is an invalid representation for the target
 of the assignment, then any use of the target object prior to a further
-assignment to the target object, other than as the prefix of a "Valid"
+assignment to the target object, other than as the prefix of a Valid
 attribute reference, is erroneous.
 
 !discussion
@@ -84,8 +84,8 @@
 is erroneous if Raw_Input does not contain one of the four bit patterns that
 are valid representations of Setting values. Execution is rendered erroneous
 by the function call in the first assignment statement. Even though an
-implementation is likely in practice to behave as expected, raising
-Input_Error, execution is, formally, unpredictable from this point on. In
+implementation is likely in practice to behave as expected (raising
+Input_Error), execution is, formally, unpredictable from this point on. In
 theory, it is permissible to generate code for an attribute X'Valid, where X is
 known to be the result of an unchecked conversion, that always yields True
 (since the only case in which the attribute would yield False is the case in
@@ -97,7 +97,7 @@
 the result can be abnormal." In the case of a scalar target type, assuming
 that the unchecked conversion produces an object with the same bit pattern as
 the actual parameter, the result will be invalid, as defined in 13.9.1(2) ("the
-object's representation does represent any value of the object's subtype").
+object's representation does not represent any value of the object's subtype").
 
 It is the intent of the Standard that a scalar unchecked-conversion result
 holding an invalid representation is not abnormal. Abnormality is a graver
@@ -111,15 +111,15 @@
 offsets may be corrupted, causing run-time checks themselves to misbehave).
 However, the only forms of corrupt scalar data are:
 
-  o a representation for an integer-type, enumeration-type, or
-    floating-point-type object that is outside the range of the object's
+  o a representation for an integer type, enumeration type, or
+    floating point type object that is outside the range of the object's
     subtype
 
-  o a representation for an enumeration-type object that is not the
+  o a representation for an enumeration type object that is not the
     representation of any value in the type
 
-  o a representation for a floating-point-type object that is not the
-    representation of any floating-point value
+  o a representation for a floating point type object that is not the
+    representation of any floating point value
 
 It is feasible to check for each of these forms of corruption, and the
 evaluation of the Valid attribute is expected to do so. (The check for an
@@ -148,7 +148,11 @@
 their own recovery mechanism for invalid data.)
 
 Therefore, we declare any use other than storing the invalid value and testing
-its validity to be erroneous.
+its validity to be erroneous. It is necessary to limit storing of invalid
+values to assignment_statements and object_declarations to prevent distributed
+overhead. For instance, passing the invalid value as a parameter is still
+erroneous; otherwise, static analysis could not assume valid values in most
+cases.
 
 
 It has been suggested that, since 13.9.1(12) applies only to scalars, a
@@ -196,17 +200,17 @@
 A call to an imported function or an instance of Unchecked_Conversion is
 erroneous if the result is scalar, the result object has an invalid
 representation, and the result is used other than as the @fa<expression> of
-an @fa<assignment_statement> or an object declaration, or as the prefix of a
-Valid attribute. If such a result object is used as the source of an
+an @fa<assignment_statement> or an @fa<object_declaration>, or as the prefix
+of a Valid attribute. If such a result object is used as the source of an
 assignment, and the assigned value is an invalid representation for the target
 of the assignment, then any use of the target object prior to a further
-assignment to the target object, other than as the prefix of a "Valid"
+assignment to the target object, other than as the prefix of a Valid
 attribute reference, is erroneous.
 
 !ACATS Test
 
 An ACATS C-test could only check that the U_C and 'Valid work; it could not
-verify the absense of erroneousness. This does not seem valuable.
+verify the absence of erroneousness. This does not seem valuable.
 
 !appendix