DECAda/VMS - calling GETJPI

DECAda/VMS - calling GETJPI

[Alan Paterson]

Here's one for the VMS gurus (I can't post it to comp.os.vms, 
'cos there's a psychopath there who throws abuse at me):

I want to examine all processes currently active. The system 
service to do this is, of course, GetJPI (either in Starlet or 
Lib). To perform wildcard process search, this procedure 
expects to receive a value of -1 for the process_id parameter. 
Unfortunately, in the "official" spec-files for these 
procedures, this parameter has the type UNSIGNED_LONGWORD. Ada, 
quite correctly, objects to this kind of thing :-)

So, what I now do is the following:

   PID  : UNSIGNED_LONGWORD;
   PID0 : INTEGER;
   for PID0 use at PID'address;
begin
   PID0 := -1;
   loop
      GetJPI(..., Process_Id => PID, ...);

This works, but I can't help but wonder if there isn't a more 
elegant way to do it. Does anyone have experience with this?
-- 
Alan Paterson
Berne, Switzerland

Re: DECAda/VMS - calling GETJPI

[Stuart Palin]

I've no specific experience of using DEC Ada with GETJPI but this looks very similar to the 
general problem Ada 83 has with unsigned integers.  Basically an unsigned type must be bound 
 by an integer range constraint (LRM 3.5.4 (3)). An unsigned longword usually creates a 
problem since the base type integer is also usally longword based.  This means the upper 
constarint on unsigned_longword is 2**32-1 which is not a valid integer expression 
(integer'last = 2**31-1).  Many implementations (certainly the version of DEC Ada I am 
using) gets around this by defining the unsigned_longword as:

   unsigned_longword is range -2**31..2**31-1;  -- or something equivalent

This creates all sorts of problems for defining values in the upper range (16#80000000# .. 
16#FFFFFFFF#) since they map on to negative values (but the bit image is correct!!).

A reasonable way of accessing these values is to define a constant:

    Hex_80000000 : constant unsigned_longword(-16#80000000#);

Now you can do things such as:

     ulong := Hex_80000000 + 16#456789AB#;

Now for your -1 value what you need to use is 16#FFFFFFFF#; (which is the bit image 
equivalent of the longword integer representation of -1); this could be defined as a 
constant:

    Hex_FFFFFFFF : constant unsigned_longword(-1);

though you will probably want to use a name more appropriate to your application.

-- 
Stuart Palin            |  GEC Marconi Avionics Ltd
Consultant Engineer     |  Airport Works
Flight Systems Division |  Rochester
G-NET 791 4197          |  Kent.  ME1 2XX

Re: DECAda/VMS - calling GETJPI

[Michael F Brenner]

Under Ada 95, assuming that unsigned_longword was defined as 
  type unsigned_longword is mod 2**64;

  or 

  type unsigned_longword is mod 2**32;

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.

However, if unsigned_longword is defined using one of the Ada-83
workarounds earlier in this thread, then the workarounds earlier in
this thread could be attempted, with appropriate tests to make sure
they are doing what you think they are doing. 

Re: DECAda/VMS - calling GETJPI

[Ken Garlington]

Alan Paterson wrote:
> 
> So, what I now do is the following:
> 
>    PID  : UNSIGNED_LONGWORD;
>    PID0 : INTEGER;
>    for PID0 use at PID'address;
> begin
>    PID0 := -1;
>    loop
>       GetJPI(..., Process_Id => PID, ...);
> 
> This works, but I can't help but wonder if there isn't a more
> elegant way to do it. Does anyone have experience with this?

I tried this on DEC Ada V3.0A-9 on a VAXStation 4000 running VMS 5.5-2.
I can assign -1 to objects of System.Unsigned_Longword just fine, so
long as the "-" operator is visible (e.g., put in a "use System;").

For this version of DEC Ada, System.Unsigned_Longword is defined as
range System.Min_Int .. System_Max_Int, with System.Min_Int = -(2**31).
See the DEC Ada documentation, or read file ADA$PREDEFINED:SYSTEM_.ADC.

If, on your version of DEC Ada, the range has been changed, try this:

  Minus_1 : constant System.Unsigned_Longword := System."not"(0);

-- 
LMTAS - "Our Brand Means Quality"

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

Micheal 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."

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.

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!

IN fact the proper solution in this case is trivial:

procedure z is
  type unsigned_longword is mod 2 ** 64;
  x: unsigned_longword := -1;
begin
   null;
end;

or, if you want the constant integer_minus_1, define it as type ul to start
with.

Re: DECAda/VMS - calling GETJPI

[Mats Weber]

In article <31B2AF74.668E@dial.eunet.ch>, Alan Paterson
<paterson@dial.eunet.ch> wrote:

>Here's one for the VMS gurus (I can't post it to comp.os.vms, 
>'cos there's a psychopath there who throws abuse at me):
>
>I want to examine all processes currently active. The system 
>service to do this is, of course, GetJPI (either in Starlet or 
>Lib). To perform wildcard process search, this procedure 
>expects to receive a value of -1 for the process_id parameter. 
>Unfortunately, in the "official" spec-files for these 
>procedures, this parameter has the type UNSIGNED_LONGWORD. Ada, 
>quite correctly, objects to this kind of thing :-)

The best way of doing this is by calling process_scan (in Starlet or lib).
I have once written a program that does all this and displays all kinds of
process info (much better than show system). If you want it, send me
e-mail and I'll give you the source.

>So, what I now do is the following:
>
>   PID  : UNSIGNED_LONGWORD;
>   PID0 : INTEGER;
>   for PID0 use at PID'address;

This is erroneous in Ada 83, and at least dangerous without a pragma
Volatile or something. You should prefer Unchecked_Conversion, which will
work when Standard.Integer becomes 64 bits.

>begin
>   PID0 := -1;
>   loop
>      GetJPI(..., Process_Id => PID, ...);
>
>This works, but I can't help but wonder if there isn't a more 
>elegant way to do it. Does anyone have experience with this?

Yes, there is:

   PID  : UNSIGNED_LONGWORD := -1;
begin
   PID := -1;
   loop
      GetJPI(..., Process_Id => PID, ...);

works because System.UNSIGNED_LONGWORD is -2**31 .. 2**31 - 1.

Re: DECAda/VMS - calling GETJPI

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

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

Mike Brenner says

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

Yes, that's right GNAT violates the Rationale here. That's because the
Rationale is wrong. TO be fair, the problem is that it reflects the
language design as it was prior to the meeting in England.

Mike, always read the RM, not the Rationale, when they disagree, the
Ratoinale has no official status whatsoever. You cannot violate the
Rationale really, since it is not an official document. You can 
disagree with it, and most certainly should, when the Rationale is
incorrect.

The RM is quite clear on this point (I notice you did not try to quote
the RM to back up your incorrect interpretation, though it is certainly
understandable that you would assume that what you read in the Rationale
was correct).

The conversion raises constraint error because the value in question is
outside the range of the target type. Nowhere in the RM can you find a
suggestion that modular types are treated specially in such
conversions because there is no such special treatment.

There are not many technical errors in the Rationale of this type. All the
ones I know about are in this category, they reflect a change to the language
made late on, where the Rationale did not track the change.

It would be quite useful to have a comprehensive errata list for the Rationale,
but I do not know of one.

Anyway, bottom line, GNAT is right, Mike is wrong!

P.S. for the RM archeologists, the most obvious reference is in section
4.6

28   For the evaluation of a type_conversion that is a value conversion, the
operand is evaluated, and then the value of the operand is converted to a
corresponding value of the target type, if any.  If there is no value of the
target type that corresponds to the operand value, Constraint_Error is
raised; this can only happen on conversion to a modular type, and only when
the operand value is outside the base range of the modular type.  Additional
rules follow:

[seems clear enough to me!]

Re: DECAda/VMS - calling GETJPI

[Ken Garlington]

Robert Dewar wrote:
> 
> IN fact the proper solution in this case is trivial:
> 
> procedure z is
>   type unsigned_longword is mod 2 ** 64;
>   x: unsigned_longword := -1;
> begin
>    null;
> end;
> 

I thought the original post required a solution compatible with DEC Ada
hosted on VAX/VMS. I don't think this solution is going to fly in that
environment :)

On the other hand, I _did_ compile my solution before posting it, so there!

-- 
LMTAS - "Our Brand Means Quality"

Re: DECAda/VMS - calling GETJPI

[Michael F Brenner]

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

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

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

 ------------
 Robert Dewar responded:
 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!

 ------------
 Mike Brenner responded:

> 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.
 
 ------------
 Robert Dewar responded: 
 
 That's right GNAT violates the Rationale here. That's because the
 Rationale is wrong. TO be fair, the problem is that it reflects the
 language design as it was prior to the meeting in England.
 
 Mike, always read the RM, not the Rationale, when they disagree, the
 Ratoinale has no official status whatsoever. You cannot violate the
 Rationale really, since it is not an official document. You can
 disagree with it, and most certainly should, when the Rationale is
 incorrect.
 
 The RM is quite clear on this point (I notice you did not try to quote
 the RM to back up your incorrect interpretation, though it is certainly
 understandable that you would assume that what you read in the Rationale
 was correct).
 
 The conversion raises constraint error because the value in question is
 outside the range of the target type. Nowhere in the RM can you find a
 suggestion that modular types are treated specially in such
 conversions because there is no such special treatment.

 There are not many technical errors in the Rationale of this type. All the
 ones I know about are in this category, they reflect a change to the language
 made late on, where the Rationale did not track the change.
 
 It would be quite useful to have a comprehensive errata list for the 
 Rationale, but I do not know of one.
 
 Anyway, bottom line, GNAT is right, Mike is wrong!
 
 P.S. for the RM archeologists, the most obvious reference is in section 4.6
 28   For the evaluation of a type_conversion that is a value conversion, the
 operand is evaluated, and then the value of the operand is converted to a
 corresponding value of the target type, if any.  If there is no value of the
 target type that corresponds to the operand value, Constraint_Error is
 raised; this can only happen on conversion to a modular type, and only when
 the operand value is outside the base range of the modular type.  
 
 [seems clear enough to me!]

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

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

For example, when converting to type integer and the value is out of range
of integer'first..integer'last, a constraint_error is generated. Since
modular types must never give a constraint_error, and since non-modular
types must always give a constraint_error when an out of range value is
provided to a type converter, this typographical error should be corrected. 

Recommendation: Fix this typographical error through the proper channels,
but in the meanwhile, change your interpretation of modular types back
to that of the Rationale, change gnat to convert modular types without
giving a constraint_error, and please give a reference to the meeting
in England which overrides the Rationale and how I can participate in 
future meetings of this sort.

Mike Brenner

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

Mike said

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

3.5.4(19) is about predefined opertors, conversion is not a predefined
opertor, so this paragraph is irrelevant to the discussion and does not 
apply.

3.5.1(1) talks about arithmetic being modular, conversion is not an
arithmetic operation in the RM sense, so this paragraph is irrelevant to
the discussion.

Mike your reading is just wrong, sorry. You seem to be tenaciously holding
on to it, but it is unsupportable. Note in particular that the idea that
-1 and 255 (or whatever) are the same mathematical integer is particularly
bizarre.

The sentence you call a typographical error is not a typographical
error at all. The sentence in question:

28   For the evaluation of a type_conversion that is a value conversion, the
operand is evaluated, and then the value of the operand is converted to a
corresponding value of the target type, if any.  If there is no value of the
target type that corresponds to the operand value, Constraint_Error is
raised; this can only happen on conversion to a modular type, and only when
the operand value is outside the base range of the modular type.  Additional
rules follow:

ONly applies to modular types, since it is only modular types where the
set of values is limited. The conceptual set of values for signed integer
types includes the full set of integers (of course subsequently a constraint
error may occur from violating a constraint on the type. For example:

  x : integer := integer (999999999999999999999999);

raises a constraint error, not because of anything in paragraph 28, but
because the resulting value violates the constraint on integer. On the
other hand

  x : integer'base := integer'base (9999999999999999999999999999);

may not necessarily raise CE, since no constraint check is required since
Integer'Base is an unconstrained type.

For modular types however, the set of values includes the full set of
values in the base type (e.g. 0,1,2,3 for mod 4) but no other values.


So this is not a typographical error, though I can see with your style
of "wishful reading" you would hope that it was one!

To repeat again, GNAT is correct, Mike's interpretatoin of the RM (aided
and abetted by some obsolete errors in the Rationale) is wrong.

The RM is not an easy document to read, and chapter 3 especially has
to be read very carefully without any sloppiness in terminology.

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

Mike asked::

"Recommendation: Fix this typographical error through the proper channels,
but in the meanwhile, change your interpretation of modular types back
to that of the Rationale, change gnat to convert modular types without
giving a constraint_error, and please give a reference to the meeting
in England which overrides the Rationale and how I can participate in
future meetings of this sort."

This was a meeting of WG9 and the DR's (one of a few joint meetings at
this stage). Of course now the DR's no longer exist, so the issue is
WG9 meetings. At these meetings, participants are members of their
appointed national delegations. You need to apply through the proper
channels which vary from country to country if you wish to be a member
of the delegation from a given country.

There was no question of "overriding" the Rationale, since as I said, it is
not an official WG9 document (or for that matter an official anything
document). What the meeting in England did was decide to change the way
modular operations were handled, and in particular to change the semantics
of conversion to avoid the implicit modular conversion. There were a number
of closely related issues, and when considered together, it was clearly
an advantageous change, as evidenced by the fact that the vote in favor
of this change was unanimous by delegations.

The Rationale is an informal attempt to describe the reasoning behind the
major design decisions. It always had the trouble of tracking a moving
target, and in this case, it tracked an earlier vresion of the RM, and
the relevant section did not get properly updated.

As I said earlier, always read the RM for technical details on the language
(or a good book like Norman Cohen's book that accurately discusses the
language). Read the RM for a general appreciation of the design princiles,
but not for technical details.

Re: DECAda/VMS - calling GETJPI

[Robert A Duff]

Robert is correct -- a type conversion of -1 to a modular type will
raise C_E.  -1 and 255 are *not* the "same mathematical integer".

Mike is, perhaps, confused between converting to a *type* and converting
to a *subtype*.  4.6(51) says that when converting to a subtype, you
first convert to the type, and then do a constraint check.  This can,
indeed, raise an exception when converting to a non-modular *subtype*,
such as Integer.  However, when converting to a *type*, the only
exceptions are when the target type is modular.

Robert's description of the history is correct: an earlier version of
Ada 9X did what Mike says, but it was changed.  (Robert has a better
memory than I as to which meeting that decision was made at, and where
the meeting was held.)

This language change explains why the Rationale is wrong -- it was
simply not updated correctly to match the RM in this case.

Nobody is actively working on the Rationale at this point, as far as I
know, so this bug in the Rationale will remain unfixed.

Bugs in the RM, on the other hand, are addressed by the ARG.  There are
instructions at the front of the RM telling where to send any comments
on the RM, so that the ARG will see them.

- Bob

Re: Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI)

[Robert Dewar]

"Probably the best long term solution would be to add an attribute
function, analogous to 'Val, that does the modulo operation as part
of the conversion.  E.g. Modular_Int'Modulo(X) would never overflow,
and would perform the modulo operation as part of the conversion.
Might be a good "Uniformity Rapporteur Group" (URG) idea..."

That sounds useful, I think we will put this in the next version of GNAT.

Re: DECAda/VMS - calling GETJPI

[Robert A Duff]

In article <4p32m3$51g@mulga.cs.mu.OZ.AU>,
Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote:
>It would be helpful if someone were to give a brief explanation
>of the arguments in favour of this design decision.

I can't remember all the details of the arguments at the time.

I think part of it was that people thought the old rules were confusing.
People felt that since -1 is simply not a value of the modular type,
that it ought to raise C_E on conversion.  Arithmetic purely within the
modular type is different -- you can never get the value -1 in the first
place.

One might like type conversions to be reversible.

    I: Integer := -1;
    subtype S1 is Integer range 0..255;
    X: S1 := 255;
    subtype S2 is Integer range -128..127;
    Y: S2 := -1;
    type M is mod 256;
    Z: M;

Now converting 255 of type M to type Integer produces 255, clearly,
and not -1.  So:

    Z := M(I); -- Contraint_Error happens here, but if it didn't, then
    I := Integer(Z); -- ...now I has changed its value, which some
                     -- might consider strange.

    Z := M(Y); -- OK.
    X := Integer(Z); -- Here, X has the same value it did before.
    
    Z := M(X); -- Contraint_Error happens here, but if it didn't, then
    Y := Integer(Z); -- ...you'd get Constraint_Error here.

Whether this would confuse is, I suppose, a matter of opinion.

Now, consider:

    procedure P(Param: in out M) is
    begin
        null;
    end P;

    I: Integer := -1;
    
    P(M(I));

Here, I is converted to type M before the call, and converted back to
type Integer after the call.  It might seem strange for a procedure
containing just a null statement to modify its parameter (changing -1 to
255).  (On the other hand, floating point types have the same trouble.)

In other cases, a call to P would raise Constraint_Error while trying to
convert back to the integer type.

Consider also modular-to-modular conversions.  E.g.:

    type M1 is mod 4;
    type M2 is mod 3;

Now, should converting from M1 to M2 and back to M1 change the value?
Or is it better to consider it an error when the conversion is not
reversible (that is, when the original value is 3)?

One final example:

    type T is range -1..100;
    type M is mod 2**32;

If we convert the value 101 of type M to SUBtype T, it will clearly
raise Constraint_Error.  Should converting 2**32-1 do the same, or
should it return -1?

- Bob

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

The basic idea here is that type conversion converts the type, but not
the value, of course floating-point to int already violates this somewhat
as Bob points out, but not quite as dramatically.

Consider the following example:

    type x is mod 10;
    subtype y is x range 0 .. 5;

    vy : y;

    vy := y (-4) -- raises constraint error
    vy := y (-6) -- ok, gives result of 4

At the meeting we accumulated a series of odd examples of this kind, and
decided that it is just a bit too weird to have type conversion generating
what amounts to a significant arithmetic computation.

P.S. in my comments in the example above, I am assuming for the moment the
old semantics. In current Ada 95, BOTH assigments to vy raise constraint
error, since -1 is not in the range 0 .. 5.

Actually to be strict, the constraint error is raised by the conversion
because -1 is not in the set of values for modular type x (0 .. 10).

Re: DECAda/VMS - calling GETJPI

[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

Wraparound on modular conversion (was: DECAda/VMS - calling GETJPI)

[Tucker Taft]

Robert is right, the letter and the intent of RM95
is that conversions to a modular type do *not* do a "modulo"
operation.  We discussed this particular issue at length during
one of the 9X language review meetings, and ultimately decided 
it this way.  This approach prevents unintended wraparound on conversion.

In retrospect, I am not positive we made the right decision, since 
I do find myself on occasion wishing there were some way to have 
the conversion do the modulo operation.

One way that will sometimes work is:

    X : Signed_Int;
    Y : Modular_Int := Modular_Int(Signed_Int'Pos(X) mod Modular_Int'Modulus);

This will do the modulo operation in "root_integer" which is fine so
long as Modular_Int'Modulus is <= System.Max_Int.  Otherwise, you
will get a compile-time error, and you may have to revert to
unchecked_conversion or to a sequence of statements that avoid
the overflow.  

For example, if Modular_Int'Modulus is > Signed_Int'Last,
the following sequence of statements will work without a
possibility of overflow:

    if X >= 0 then
        Y := Modular_Int(X);
    else
	-- X is < 0, make it positive, convert, and then subtract
	--  with wraparound.
        Y := Modular_Int(X - Signed_Int'First) - 
               (Modular_Int(-1 - Signed_Int'First) + 1);
    end if;

Probably the best long term solution would be to add an attribute
function, analogous to 'Val, that does the modulo operation as part
of the conversion.  E.g. Modular_Int'Modulo(X) would never overflow,
and would perform the modulo operation as part of the conversion.
Might be a good "Uniformity Rapporteur Group" (URG) idea...

-Tucker Taft   stt@inmet.com
Intermetrics, Inc.

Re: DECAda/VMS - calling GETJPI

[Fergus Henderson]

dewar@cs.nyu.edu (Robert Dewar) writes:

>What the meeting in England did was decide to change the way
>modular operations were handled, and in particular to change the semantics
>of conversion to avoid the implicit modular conversion. There were a number
>of closely related issues, and when considered together, it was clearly
>an advantageous change, as evidenced by the fact that the vote in favor
>of this change was unanimous by delegations.

It would be helpful if someone were to give a brief explanation
of the arguments in favour of this design decision.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

Ken Garlington said, replying to a post by me

"> procedure z is
>   type unsigned_longword is mod 2 ** 64;
>   x: unsigned_longword := -1;
> begin
>    null;
> end;
>

I thought the original post required a solution compatible with DEC Ada
hosted on VAX/VMS. I don't think this solution is going to fly in that
environment :)"

Sure, that's true enough, but I was responding to some incorrect Ada 95
code that was proposed with some correct Ada 95 code!

But it cerainly will not work on Dec Ada hosted on VAX/VMS :-(

Maybe one day we will be able to compile the above program on VAX/VMS
who can tell? :-)

Re: DECAda/VMS - calling GETJPI

[George Haddad]

Robert Dewar wrote:
> Consider the following example: 
>     type x is mod 10;
>     subtype y is x range 0 .. 5;

   [snip]

> Actually to be strict, the constraint error is raised by the
> conversion because -1 is not in the set of values for
> modular type x (0 .. 10).

   At last!  An opportunity to nitpick one of the comp.lang.ada 
greats.  (Or embarrass myself horribly -- you be the judge.  :-))  I 
would certainly hope that the allowable range of values for type x
is 0..9.  ;-)  Otherwise, what about this:

   V1 : constant x := 0;
   V2 : constant x := 10;
   if (V1 = V2) then Text_IO.Put_Line("Zero equals Ten."); end if;
-- 
I found these opinions on my doorstep, would you please give them a 
good home?

Re: DECAda/VMS - calling GETJPI

[Norman H. Cohen]

In article <4p547s$n99@krusty.irvine.com>, adam@irvine.com
(Adam Beneschan) writes: 

|> mfb@mbunix.mitre.org (Michael F Brenner) writes: 
...
|>  >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.

It's not a typo, but it is a case of the RM getting overly pedantic and
obscure.  For reasons that Tucker may remember but I do not, all numeric
types other than modular types are described as having an infinite "set
of values", some of which belong to a finite "base range": 

   RM95 3.5.4(8): "The set of values for a signed integer type is the
      (infinite) set of mathematical integers, though only values of the
      base range of the type are fully supported for run-time operations.
      The set of values for a modular integer type are the values from 0
      to one less than the modulus, inclusive."

   RM95 3.5.6(8): "The set of values of a floating-point type is the
      (infinite) set of rational numbers."

   RM95 3.5.9(8): "The set of values of a fixed-point type comprise
      integral multiples of number called the _small_ of the type."

(Base ranges are described in RM95 3.5(6).)

Thus RM95 4.6(28) is correct when it states: 

    "If there is no value of the target type that corresponds to the
    operand value, Constraint_Error is raised.  This can only happen on
    conversion to a modular type, and only when the operand value is
    outside the base range of the modular type."

(Nonnumeric value conversions are always to a target type that has a
corresponding value for each value of the operand type.  Since all
numeric types other than modular types are conceptually infinite,
conversions to a numeric type other than a modular type are always to
such a target type; conversions to a modular type are not.)  The word
"This" in 4.6(28) refers to the raising of Constraint_Error specifically
because there is no corresponding value in the target type, not to the
raising of Constraint_Error in general.

Yet we all know that given the declaration

   type T is range 1 .. 10;

the conversion T(11) raises Constraint_Error, so what's going on here?
The answer is found in RM95 4.6(51): "After conversion of the value to
the target type, if the target subtype is constrained, a check is
performed that the value satisfies this constraint."

In short, a value conversion consists of converting to the target type,
which can only raise Constraint_Error when the target type is a modular
type, followed by a check that the converted value obeys the constraint
of the target subtype, which generally has the potential to raise
Constraint_Error for any target type.

--
Norman H. Cohen    ncohen@watson.ibm.com

Re: DECAda/VMS - calling GETJPI

[Robert Dewar]

George said

"   At last!  An opportunity to nitpick one of the comp.lang.ada
greats.  (Or embarrass myself horribly -- you be the judge.  :-))  I
would certainly hope that the allowable range of values for type x
is 0..9.  ;-)  Otherwise, what about this:

   V1 : constant x := 0;
   V2 : constant x := 10;
   if (V1 = V2) then Text_IO.Put_Line("Zero equals Ten."); end if;"

A correct nitpick indeed :-)
yes, of course I meant 0 .. 9 (to bad there is no way to compile and test
english commentary containing odd bits of Ada :-)

The code snippet above is statically illegal, because 10 is outside he
base range (the type x is mod 10 in this example).

P.S. sorry for missed characters and transposed characters in my posts, my
keyboard is sticking and fighting, but I am finally getting it replaced
next week, so that should help :-)

Re: DECAda/VMS - calling GETJPI

[Adam Beneschan]

In article <4p9k71$11a1@watnews1.watson.ibm.com> ncohen@watson.ibm.com writes:
 >Thus RM95 4.6(28) is correct when it states: 
 >
 >    "If there is no value of the target type that corresponds to the
 >    operand value, Constraint_Error is raised.  This can only happen on
 >    conversion to a modular type, and only when the operand value is
 >    outside the base range of the modular type."
 >

Thank you for explaining the meaning of this paragraph so clearly.

                                -- Adam