--- ais/ai-00186.txt 1999/03/22 23:42:41 1.2 +++ ais/ai-00186.txt 2004/04/06 19:56:56 1.3 @@ -1,4 +1,4 @@ -!standard 03.05.04 (14) 99-03-21 AI95-00186/02 +!standard 03.05.04 (14) 04-03-23 AI95-00186/03 !standard 03.04 (9) !class binding interpretation 99-03-21 !status work item 97-03-19 @@ -7,15 +7,15 @@ !difficulty Medium !subject Range of root_integer -!summary 99-03-21 +!summary An implementation may support integer or modular types which include -values outside the range System.Min_Int..System.Max_Int. In some cases -evalutation of a non-static root_integer expression outside this range is -required not to raise an exception. In most other such cases, the behavior +values outside the range System.Min_Int..System.Max_Int. In some cases +evaluation of a non-static root_integer expression outside this range is +required not to raise an exception. In most other such cases, the behavior is defined to be implementation dependent. -!question 99-03-21 +!question Consider for example: @@ -32,7 +32,7 @@ Is the evaluation of the expression allowed to raise Constraint_Error if P is instantiated with the largest modular type? (No.) -!recommendation 99-03-21 +!recommendation If an implementation supports a modular type whose range exceeds 0..System.Max_Int, or a nonstandard integer type with values outside @@ -48,7 +48,7 @@ expression is within the range of the target type. Let T be an integer or modular type which has values outside the range -System.Min_Int..System.Max_Int. If a non-static expression of type +System.Min_Int..System.Max_Int. If a non-static expression of type root_integer has both an attribute, variable or result of type T and an attribute, variable or result of some other type, it is erroneous for the value of the expression to exceed the range of root_integer. @@ -56,7 +56,7 @@ An implementation is allowed to choose a range for root_real that exceeds System.Min_Int..System.Max_Int. -!wording 99-03-21 +!wording The second sentence of paragraph 3.4(9) should read: @@ -67,33 +67,33 @@ "A type defined by an integer_type_definition is implicitly derived from _root_integer_, an anonymous predefined (specific) integer type, -whose base range is {at least} System.Min_Int..System.Max_Int. However, +whose base range is {at least} System.Min_Int..System.Max_Int. However, the base range of the new type is not inherited from root_integer, but is instead determined by the range or modulus specified by the -integer_type_definition. Integer literals are all of the type +integer_type_definition. Integer literals are all of the type _universal_integer_, the universal type (see 3.4.1) for the class rooted at _root_integer_, allowing thier use with the operations of any integer type." -!discussion 99-03-21 +!discussion The first wording change above is just to eliminate an apparent conflict in -the standard. The second sentence of 3.5.4(14) is correct, but since all +the standard. The second sentence of 3.5.4(14) is correct, but since all integer types are derived types, the paragraphs conflict. The main problem dealt with here is caused by the preference rule (see -8.6(29)) for root_integer. In theory this can cause expressions which +8.6(29)) for root_integer. In theory this can cause expressions which appear to involve only operations of of one numeric type to actually be -evaluated using the operations of root_integer. Consider for instance the +evaluated using the operations of root_integer. Consider for instance the expression T'Val(T'Pos(X) - 3) where X is of type T. Although all the values in the expression are of either type T or universal_integer, the subtraction operation is that of root_integer. This seems irksome, but unlikely to occur even inside a generic with a -formal of a discrete type. However, there are more troubling cases. +formal of a discrete type. However, there are more troubling cases. Consider the Boolean expression S'Modulus > T'Modulus, where S and T are -modular subtypes. When is this illegal, guaranteed to work, or can +modular subtypes. When is this illegal, guaranteed to work, or can possibly raise Constraint_Error? If the answer depends on the staticness -of the subtypes, that way lies madness. (Note that in this particular +of the subtypes, that way lies madness. (Note that in this particular case, the expression can always be evaluated at compile time even if the subtypes are static or generic formal subtypes.) @@ -108,9 +108,9 @@ Does this or should this raise Constraint_Error, or is it implementation dependent? (It is implementation dependent if the subtype is non-static.) -Now let's look at the other side for a minute. There are some truly ugly +Now let's look at the other side for a minute. There are some truly ugly cases such as X: Integer := Modular'Pos(Y) + Integer'Pos(Z); where Y and Z -are varibles of the respective types. Here we have an expression that can +are variables of the respective types. Here we have an expression that can only be evaluated at run-time, and possibly no machine arithmetic types that can be used safely, assuming that Integer and Modular are the largest available integer and modular types respectively. @@ -118,25 +118,31 @@ The conclusion is that implementations should always be allowed to "do the right thing" in the reasonable cases, and required not to raise Constraint_Error in expressions without attributes of a single type but no -arithmetic operations. But rather than force implementations not to +arithmetic operations. But rather than force implementations not to provide otherwise useful types by requiring support of some pathological -cases, these case are made erroneous. It would be possible to make these +cases, these case are made erroneous. It would be possible to make these cases a bounded error, but such mixed expressions can (and should) always be rewritten to make explicit which operations should be modular and where -overflow is wanted. By making such expressions erroneous only if they +overflow is wanted. By making such expressions erroneous only if they exceed the range of root_integer, programmers can still use such expressions if they know the possible ranges of all intermediate results. Finally this AI allows the range of root_integer to exceed -System.Min_Int..System.Max_Int. There is no point in allowing nonstandard +System.Min_Int..System.Max_Int. There is no point in allowing nonstandard integer types if the implementations are then restricted from using them -where appropriate. For example, on a machine with a double-width +where appropriate. For example, on a machine with a double-width multiplication result and easy addition and subtraction for such values, it would be useful to have that type as a nonstandard integer type, even if some multiplication operators were not provided, and you couldn't use it -for indexing. It would be silly to prohibit using that type for evaluating -expressions of type root_real. Where possible this is the best solution to +for indexing. It would be silly to prohibit using that type for evaluating +expressions of type root_real. Where possible this is the best solution to the problem. + +!ACATS Test + +ACATS C-Tests should be created to check that a generic instantiated with the +largest modular type does not overflow. The other cases are +implementation-defined and thus are difficult to test. !appendix 97-03-19

Questions? Ask the ACAA Technical Agent