CVS difference for ais/ai-00186.txt

Differences between 1.2 and version 1.3
Log of other versions for file ais/ai-00186.txt

--- 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