Range checking extended values AI-00891/00 1
91-02-11 ra WI
!standard 11.06 (06) 91-02-11 AI-00891/00
!class ramification 91-02-11 (provisional classification)
!status work-item 91-02-11
!status received 91-02-11
!topic Range checking extended values
!summary 91-02-11 (DRAFT)
[To be determined after ARG discussion.]
!question 91-02-11 (DRAFT)
11.6(6) says:
Similarly, additional freedom is left to an implementation for the
evaluation of numeric simple expressions. For the evaluation of a
predefined operation, an implementation is allowed to use the
operation of a type that has a range wider than that of the base type
of the operands, provided that this delivers the exact result (or a
result within the declared accuracy, in the case of a real type),
even if some intermediate results lie outside the range of the base
type. The exception NUMERIC_ERROR need not be raised in such a case.
In particular, if the numeric expression is an operand of a
predefined relational operator, the exception NUMERIC_ERROR need not
be raised by the evaluation of the relation, provided that the
correct BOOLEAN result is obtained.
The first two sentences of 11.6(6) specifically allow expressions to be
computed with greater accuracy or range than would otherwise be determined
from the base type of the expression. Implementations of Ada on IEEE hardware
may well have the property that the predefined operations on type FLOAT
actually use extended precision. In this context, the following questions
arise:
a. Given an expression "FLOAT(expr)", can an implementation omit a
range check upon the value of "expr", or it is required to raise
CONSTRAINT_ERROR (or NUMERIC_ERROR, given AI-00387)?
b. Given "expr in FLOAT", can the result be false?
c. Given "X : FLOAT := expr;", must an exception be raised for the
assignment, assuming the "expr" has an extended value?
d. Given "P(expr)" where P has an in parameter of type FLOAT and
"expr" has an extended value, must an exception be raised?
If an exception must be raised in case 1, would the same answer apply if
"expr" were a real literal? If so, this would not allow number declarations
to be used to compute extended values (for instance). This interpretation
would not be particularly helpful.
DRAFT DRAFT DRAFT
Range checking extended values AI-00891/00 2
91-02-11 ra WI
!response 91-02-11 (DRAFT)
[To be determined after ARG discussion.]
!appendix 91-02-18
*****************************************************************************
!section 11.06 (06) B Wichmann 90-12-21 83-01406
!version 83
!topic Range checking extended values
The first two sentences of 11.6(6) specifically allow expressions to be
computed with greater accuracy or range than would otherwise be determined
from the base type of the expression. Implementations of Ada on IEEE hardware
may well have the property that the predefined operations on type FLOAT
actually uses extended precision. In this context, the following questions
arise:
a) Given an expression "FLOAT(expr)", can an implementation omit a range
check upon the value of expr, or it is required to raise
CONSTRAINT_ERROR?
b) Given "expr in FLOAT", can the result be false?
c) Given "X: FLOAT := expr;", must an exception be raised for the
assignment, assuming the "expr" has an extended value?
d) Given "P(expr)" where P has an in parameter of type FLOAT and "expr"
has an extended value, must an exception be raised?
In appears that 11.6(6) refers only to 'predefined operations' while the
above are examples of 'basic operations'. If this distinction is intended
in this case, then such extended values should not be allowed in such
contexts giving the results:
a) range check required
b) will give FALSE for extended values
c) will raise CONSTRAINT_ERROR for extended values
d) will raise CONSTRAINT_ERROR for extended values
However, the same would then apply to implicit conversions of values of
type universal_real, which would not allow number declarations to be used
to compute extended values (for instance). This interpretation in this one
case seems rather unhelpful.
DRAFT DRAFT DRAFT
Range checking extended values AI-00891/00 3
91-02-11 ra WI
*****************************************************************************
!section 11.06 (06) J. Goodenough 91-02-18
!version 1983
!topic Discussion of examples
It would seem to be clear that FLOAT(expr) need not raise an exception if
"expr" is held with extended precision and has a value that is greater than
FLOAT'LAST or less than FLOAT'FIRST. Hence the implicit conversion of a
numeric literal to a real base type such as FLOAT also need not raise an
exception.
On the other hand, it would appear that if the value of "expr" is greater
than FLOAT'LAST or less than FLOAT'FIRST, then
expr in FLOAT
must return FALSE. This is justified because the above expression is not a
numeric simple expression and hence, extra precision is not allowed.
For the assignment
X : FLOAT := expr;
an exception must be raised (leaving aside optimization issues concerning
whether X is a dead variable or not) since X is not allowed to hold a value
outside its base type's range.
Similarly, for a procedure call
P(expr);
it would appear that a range check against the base type must be made.
Requiring such a check is a bit peculiar since it effectively does not allow
the extended precision value to be passed as a parameter, even if P is
inlined, and this seems counter-productive.
DRAFT DRAFT DRAFT