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
Questions? Ask the ACAA Technical Agent