CVS difference for ais/ai-00167.txt

Differences between 1.6 and version 1.7
Log of other versions for file ais/ai-00167.txt

--- ais/ai-00167.txt	2002/10/29 20:24:56	1.6
+++ ais/ai-00167.txt	2003/03/04 04:56:21	1.7
@@ -1,25 +1,18 @@
-!standard 13.09.01 (12)                               02-09-25  AI95-00167/02
+!standard 13.09.01 (12)                               03-02-09  AI95-00167/03
 !class binding interpretation 98-03-18
+!status Amendment 200Y 03-02-19
+!status ARG Approved 6-2-0  03-02-09
 !status work item 98-03-18
 !status received 96-11-16
 !priority Low
 !difficulty Hard
-!subject Scalar unchecked conversion is never erroneous
+!subject Scalar unchecked conversion can be used with 'Valid to prevent erroneousness
 
 !summary
 
-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 source of an
-assignment operation or the prefix of a "Valid" attribute reference. 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"
-attribute reference, is erroneous.
+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.
 
-NOTE: The above is intended as replacement wording for 13.9.1(2).
-
 !question
 
 13.9.2(1) says, "The Valid attribute can be used to check the validity of data
@@ -30,7 +23,7 @@
 check the validity of an unchecked-conversion result without rendering
 execution erroneous in the case that the result is invalid?
 
-!response
+!recommendation
 
 If a call to an imported function or an instance of Unchecked_Conversion
 returns a scalar object that has an invalid representation, paragraph
@@ -39,6 +32,20 @@
 prefix of 'Valid. Otherwise, there is no way to make use of the 'Valid
 attribute to check the validity of the result, as implied by 13.9.2(1).
 
+!wording
+
+Replace 13.9.1(12) by:
+
+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"
+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"
+attribute reference, is erroneous.
+
 !discussion
 
 Implementations that already provide the desired behavior (i.e., disregarding
@@ -124,41 +131,27 @@
 As explained by the note in 13.9.2(12), evaluation of the attribute X'Valid
 does not entail "evaluating the value" of X. Therefore, the Valid attribute of
 a scalar unchecked-conversion result can always be evaluated without generating
-a bounded error. More importantly, an unchecked conversion that returns an
-invalid result does not render execution erroneous.
+a bounded error.
+
 
-The use of an invalid unchecked-conversion result in other contexts may result
-in a bounded error, but not in erroneous execution. The following example
-illustrates the importance of this distinction:
-
-   case Bits_To_Setting(Raw_Input) is
-      when Off => ...
-      when Low => ...
-      when Medium => ...
-      when High => ...
-   end case;
-
-Suppose Raw_Input does not contain the representation of any Setting value. If
-the execution of the unchecked conversion were considered erroneous, it would
-be permissible for the implementation to ignore the possibility of an invalid
-result. That is, the implementation could optimize away the check called for
-by 5.4(13), which verifies that the value of a case-statement expression is
-covered by one of the case statement's discrete choice lists. The
-justification for eliminating the check is that the check can only fail during
-erroneous executions, and any behavior is permissible during erroneous
-execution. If the check is eliminated, an invalid result could cause a branch
-to an arbitrary address, with catastrophic results.
-
-In fact, the unchecked conversion is not erroneous, but the object it returns
-contains an invalid representation. The execution of the case statement
-entails the evaluation of this object to obtain its value, and this evaluation
-is a bounded error. The possible consequences of this bounded error are
-enumerated in 13.9.1(9):  Constraint_Error or Program_Error can be raised, or
-execution can continue using the invalid representation. If execution
-continues using the invalid representation, the check stipulated by 5.4(13) is
-performed, raising Constraint_Error.
+We considered repealing 13.9.1(12) altogether. In this case, 13.9.1(9) would
+apply, and use of the invalid value would cause a bounded error.
 
-(It has been suggested that, since 13.9.1(12) applies only to scalars, a
+This solution was rejected because it would have distributed overhead costs on
+implementations. An implementation would no longer be able to assume that an
+object, once initialized to a valid value, would stay valid. This would prevent
+optimization of many constraint checks. An alternative to that would be to
+effectively do a 'Valid check on the result of every call to
+Unchecked_Conversion or imported function, raising Program_Error on failure.
+Such an implementation would have both extra overhead and would effectively
+be taking control of data validity out of the user's hands. (They may have
+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.
+
+
+It has been suggested that, since 13.9.1(12) applies only to scalars, a
 programmer can avoid erroneous execution by having the unchecked conversion
 return a one-element record containing the scalar:
 
@@ -191,7 +184,29 @@
 However, by 13.9(11), Bits_To_Setting_Container is permitted to return an
 abnormal object if Raw_Input does not contain the representation of a
 Setting_Container value. Then evaluation of the call on
-Bits_To_Setting_Container is erroneous by 13.9.1(8).)
+Bits_To_Setting_Container is erroneous by 13.9.1(8).
+
+!corrigendum 13.9.1(12)
+
+@drepl
+A call to an imported function or an instance of Unchecked_Conversion is
+erroneous if the result is scalar, and the result object has an invalid
+representation.
+@dby
+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
+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"
+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.
 
 !appendix
 

Questions? Ask the ACAA Technical Agent