CVS difference for ais/ai-00167.txt

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

--- ais/ai-00167.txt	2001/12/22 04:11:55	1.5
+++ ais/ai-00167.txt	2002/10/29 20:24:56	1.6
@@ -1,4 +1,4 @@
-!standard 13.09.01 (12)                               01-01-29  AI95-00167/01
+!standard 13.09.01 (12)                               02-09-25  AI95-00167/02
 !class binding interpretation 98-03-18
 !status work item 98-03-18
 !status received 96-11-16
@@ -6,14 +6,22 @@
 !difficulty Hard
 !subject Scalar unchecked conversion is never erroneous
 
-!summary 98-03-18
+!summary
 
-Scalar results produced by unchecked conversions or calls on imported
-subprograms may be invalid, but not abnormal.  The execution of such a call is
-not inherently erroneous.
+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.
 
-!question 98-03-18
+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
 produced by unchecked conversion, input, interface to foreign languages, and
 the like," but 13.9.1(12) says, "A call to an imported function or an instance
@@ -22,18 +30,16 @@
 check the validity of an unchecked-conversion result without rendering
 execution erroneous in the case that the result is invalid?
 
-!response 98-03-18
+!response
 
 If a call to an imported function or an instance of Unchecked_Conversion
-returns a scalar object whose representation is not the representation of any
-value in the return subtype, or if a call to an imported procedure causes a
-scalar actual parameter to hold a representation that is not the representation
-of any value in the parameter subtype, the function result or actual parameter
-holds an invalid representation, but is not abnormal.  Notwithstanding
-13.9.1(12), the fact that the subprogram call produced an invalid
-representation does not make execution of the call erroneous.
+returns a scalar object that has an invalid representation, paragraph
+13.9.1(12) makes any use of such a value erroneous. This paragraph should have
+made a special case for a use as the right hand side of an assignment or the
+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).
 
-!discussion 98-03-18
+!discussion
 
 Implementations that already provide the desired behavior (i.e., disregarding
 the fact that execution is formally erroneous in the case of an invalid
@@ -69,10 +75,10 @@
    end if;
 
 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
+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
+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
@@ -81,22 +87,22 @@
 13.9(10) and 13.9(11) stipulate that if the representation of the actual
 parameter of an unchecked conversion is not "the representation of an object of
 the target subtype," then "the effect is implementation-defined; in particular
-the result can be abnormal."  In the case of a scalar target type, assuming
+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").
 
 It is the intent of the Standard that a scalar unchecked-conversion result
-holding an invalid representation is not abnormal.  Abnormality is a graver
-condition than invalidity.  By 13.9.1(1), it is a bounded error to "evaluate
-the value" of an object with an invalid representation.  This bounded error may
+holding an invalid representation is not abnormal. Abnormality is a graver
+condition than invalidity. By 13.9.1(1), it is a bounded error to "evaluate
+the value" of an object with an invalid representation. This bounded error may
 result in an exception or in the use of the invalid representation value, but
-not in arbitrary behavior.  In contrast, an abnormal object is considered so
+not in arbitrary behavior. In contrast, an abnormal object is considered so
 seriously corrupted that it is erroneous even to evaluate its name, even as the
-prefix of some enclosing name.  Such serious corruption can occur in some
+prefix of some enclosing name. Such serious corruption can occur in some
 composite objects (for example, dope vectors, discriminants, or internal
-offsets may be corrupted, causing run-time checks themselves to misbehave).  H
-owever, the only forms of corrupt scalar data are:
+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
@@ -109,20 +115,20 @@
     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
+evaluation of the Valid attribute is expected to do so. (The check for an
 invalid representation in an enumeration type with gaps may entail a binary
-search of a table of valid representations.  The check for an invalid
+search of a table of valid representations. The check for an invalid
 floating-point representation may entail loading a value into a floating-point
 register or adding 0.0 to it, and responding to a resulting hardware trap.)
 
 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
+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
+a bounded error. More importantly, an unchecked conversion that returns an
 invalid result does not render execution erroneous.
 
 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
+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
@@ -132,23 +138,23 @@
       when High => ...
    end case;
 
-Suppose Raw_Input does not contain the representation of any Setting value.  If
+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
+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
+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
+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
+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
+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
+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.
 
@@ -184,10 +190,10 @@
 
 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
+Setting_Container value. Then evaluation of the call on
 Bits_To_Setting_Container is erroneous by 13.9.1(8).)
 
-!appendix 96-11-16
+!appendix
 
 !section 13.9.1(12)
 !subject Erroneous scalar Unchecked_Conversion?
@@ -514,6 +520,33 @@
 
 I would agree with Robert's assertion too, as M. Random-User.  Is this the
 one attribute the only one way we do not want to optimize away?
+
+****************************************************************
+
+From: Randy Brukardt
+Date: Friday, October 25, 2002  8:50 PM
+
+Some comments on the AI-167 write-up that was passed out at the ARG meeting:
+(this will be version /02 next time I upload AIs.)
+
+There was an incorrect paragraph reference in the !response (it should be
+13.9.1(12), not 13.9.1(2)), which I've fixed in the to-be-posted version.
+
+The !discussion section (unchanged from the previous version) should include
+an example like the one we discussed in Cupertino (where an assignment
+discards bits). (It's in the minutes of that meeting.)
+
+The discussion spends a lot of words discussing whether a UC with a scalar
+result type ever produces an abnormal result. It would seem that this is
+allowed by 13.9(11). Do we need a wording change to insure that doesn't
+happen?
+
+It's not clear to me that we actually can make such a statement
+(implementation-defined is just that; if the implementor wants to say that
+all such UCs are erroneous, that seems to be an acceptable answer). But we
+could make an AARM note to the effect that scalar UCs should either produce
+a legitimate value or an invalid representation. Or perhaps Implementation
+Advice to that effect?
 
 ****************************************************************
 

Questions? Ask the ACAA Technical Agent