Re: DECAda/VMS - calling GETJPI

[mfb@mbunix.mitre.org (Michael F Brenner)]

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. 

> Robert Dewar wrote:
> It's probably time again to repost the plea that if you suggest a solution
> to a problem, compile an example and make sure it works. No one is realiable
> enough to be 100% accurate without such a backup check, and posting incorrect
> information on Ada can cause a lot of confusion!

I compiled my example before posting this, and reported it as a bug
in gnat, with an example. The fact that it fails in gnat does not mean
the solution is erroneous; the other possibility is that the gnat
interpretation of the Reference Manual and Rationale violates the
above sentences. Gnat's erroneous interpretation places us at risk of 
creating another notorious irritation, another unexpected constraint_error,
a needless inefficiency, and a contradiction to the meaning of the words:
Modular, Cycle, Sliding, Reduced, Wrap-Around Semantics, Useful, and 
Cannot Occur.

Recommendation: To avoid causing a lot of confusion, please change gnat
to comply with the above sentences from the Reference Manual and Rationale,
permitting modular, cyclical, reduced, wrap_around semantics to occur when
converting a signed integer to an unsigned integer, providing a Useful
operation where constraint_error does not occur.

Mike Brenner <mikeb@mitre.org>

> Mike Brenner said:
> 
> "you could just assign it:
> 
>   integer_minus_1: integer := -1;
>   x: unsigned_longword := unsigned_longword (integer_minus_1);
> 
> because Ada 95 modular types truncate numbers to their modular range
> without giving a constraint_error."
>
> 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:
> 
>      1. procedure z is
>      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
>      5. begin
>      6.    null;
>      7. end;
>
> Yes, you can apply the unary minus operator to an unsigned vaue and get
> modular results as expected, but here the minus is applied to a signed
> type and generates a real minus one, which is definitely outside the
> range of any unsigned type.