Re: DECAda/VMS - calling GETJPI

[adam@irvine.com (Adam Beneschan)]

mfb@mbunix.mitre.org (Michael F Brenner) writes:
 
 > Robert Dewar replied:
 >
 >> That's quite wrong, the type conversoin checks that the value is in
 >> range, and the value is outside the range. Indeed if you add a constant
 >> to the declaration of integer_minus_1, the out of range condition will
 >> be detected at compile time by GNAT:
 >>      2.   type ul is mod 2 ** 64;
 >>      3.   integer_minus_1: constant integer := -1;
 >>      4.   x: ul := ul (integer_minus_1);
 >>                        |
 >>         >>> warning: static value out of range of type "ul" defined at line 2
 >>         >>> warning: "constraint_error" will be raised at runtime
. . . 
 > ------------
 > Mike Brenner responded:
 >
 >> That's quite right, GNAT gives the error message below, but in doing
 >> so it violates the Ada 95 Reference Manual and Rationale. Specifically, 
 >> (Rationale 3.3.2 fourth paragraph): The normal arithmetic operations
 >> apply [to modular types] ... overflow cannot occur. (3.3.2 fifth paragraph) 
 >> Conversion from modular to signed integer types works in a useful manner 
 >> so that overflow does not occur. (3.3.2 sixth paragraph) We can think 
 >> of this conversion as being somewhat akin to the sliding of array
 >> conversions. (2.12) ... the removal of the notorious irritation that
 >> for I in -1..100 loop was not allowed in Ada 83. It is allowed in Ada 9X.
 >> (3.8) We have generalized implicit subtype conversions on arrays (sliding)
 >> to apply in more circumstances. These new rules should minimize the times
 >> when an unexpected constraint_error arises when the length of the array
 >> value is appropriate, but the upper and lower bounds do not match the 
 >> applicable index constraint. ... the bounds may be freely readjusted to fit
 >> the context. (3.3.2 paragraph 2) The modular types are unsigned integer
 >> types which exhibit cyclic arithmetic. They thus correspond to the 
 >> unsigned types of some other languages such as C. (RM 3.5.4(1)) A modular
 >> type is an integer type with all arithmetic modulo a specified positive
 >> modulus. Such a type corresponds to an unsigned type with wrap-around
 >> semantics. (RM 3.5.4(19)) For a modular type, if the result of
 >> the execution of a predefined operator (see 4.5) is outside the base
 >> range of the type, the result is reduced modulo the modulus of the type
 >> to a value that is within the base range of the type. For a signed integer
 >> type, the exception constraint_error is raised by the execution of an 
 >> operation that cannot deliver the correct result because it is outside
 >> the base range of the type. For any integer type constraint_error is 
 >> raised by the operators /, REM, and MOD if the right operand is zero.
 >> (RM 4.6(30)) Numeric Type Conversion: If the target and the operand types
 >> are both integer types, then the result is the value of the target type
 >> that corresponds to the same mathematical integer as the operand. 
. . . 
 >Mike Brenner responds
 >
 >Six of the quotes came from the Rationale, three of the quotes came from the
 >RM, and there is no contradiction between the six and the three. The gnat
 >interpretation is an inefficient interpretation because it requires extra
 >checks and extra consternation on the part of maintenance and development
 >programmers. The gnat interpretation is an incorrect interpretation because
 >it does not comply with the Reference Manual 3.5.4(19) requiring reduction
 >modulo the modulus; it does not comply with the Reference Manual 3.5.4(1)
 >requiring ALL arithmetic to be modulo the modulus (including type casting);
 >it does not comply with Reference Manual 4.6(30) requiring type conversion
 >to go to the same mathematical integer, which according to Reference Manual
 >3.5.4(1) is modulo the modulus.  
 
Sorry, Mike, but 3.5.4(19) isn't relevant.  3.5.4(19) talks about the
result of the execution of a predefined operator; and type conversion
is not a predefined operator.  See 4.5.

3.5.4(1) really doesn't apply either, since it says "all arithmetic
[is] modulo a specified positive modulus."  Type conversions really
don't qualify as arithmetic, although I suppose that could be open to
debate.  The RM doesn't define the term "arithmetic".

 >
 >After going modulo the modulus, no number can be outside the range of a 
 >modular type. 
 >
 >Paragraph 28 of Section 4.6 states that constraint_error on conversion
 ><can only happen on conversion to a modular type>. This is a typographical
 >error. It makes no sense, and it contradicts both the above three
 >paragraphs in the Reference Manual, and it contradicts the fact that
 >constraint_error is raised only on converting to a non-modular type. 
 >
 >It should be changed to read <can only happen on conversion to a 
 >non-modular type>. 
 
I'm not qualified to determine whether this is a typo.  Actually, the
only people that can say for sure are those involved in writing the
RM.  I'll have to admit that I don't know what the paragraph as
written means.
 
                                -- Adam