Re: Integer'Size < 32 ?

Re: Integer'Size < 32 ?

[W. Wesley Groleau (Wes)]

There have been many good answers to the two questions about 16 bit
integers (IMHO Dewar's was the clearest) but none of them mentioned
one detail:

One of the queries suggested that constraint_error would be raised
if the compiler did not have a big enough predefined integer type.

The truth is, if such a type is not supported, the compiler is supposed
to refuse to compile the program.

But I have a related question: many of the posts on the topic repeated
the definition

   .... range -(2**31) .. ((2**31)-1)

I once used a compiler for which Integer'Size = 32 and which had an
interesting "feature."  It recognized that the above would fit in 32 bits,
so it compiled for that size.  Then at run-time, it would (obeying
the precedence rules) try to compute 2**31 and raise constraint_error.
(I didn't use the parentheses, but that doesn't change the semantics.)
The ugly work-around was

   .... range  -2**31 .. 2**30 + (2**30 - 1);

My question is, "Is this a common 'feature'?"  (Since so many people have
quoted the same example, I presume the answer is 'no')

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Hughes Defense Communications (MS 10-40)                 Home: 219-471-7206
Fort Wayne,  IN   46808                  (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Integer'Size < 32 ?

[Robert A Duff]

In article <9608081258.AA02749@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>   .... range -(2**31) .. ((2**31)-1)
>
>I once used a compiler for which Integer'Size = 32 and which had an
>interesting "feature."  It recognized that the above would fit in 32 bits,
>so it compiled for that size.  Then at run-time, it would (obeying
>the precedence rules) try to compute 2**31 and raise constraint_error.

If you mean "type T is range -(2**31) .. ((2**31)-1);", then this cannot
cause C_E, and never could, and would be a serious compiler bug if it
did.

I think you're thinking of this slightly different case:

    subtype S is Integer range 1..(2**31)-1; -- Assume Integer'Last = (2**31)-1.

In Ada 83, the above *might* raise C_E.  There was one compiler that I
know of that would raise C_E -- all others I ever used would get the
right answer.

This problem has been fixed in Ada 95.  In Ada 95 all static expressions
are evaluated exactly, at compile time, without overflow.  Therefore,
the above cannot raise C_E in Ada 95.

- Bob

Re: Integer'Size < 32 ?

[Robert Dewar]

Wes asks

"   .... range -(2**31) .. ((2**31)-1)

I once used a compiler for which Integer'Size = 32 and which had an
interesting "feature."  It recognized that the above would fit in 32 bits,
so it compiled for that size.  Then at run-time, it would (obeying
the precedence rules) try to compute 2**31 and raise constraint_error.
(I didn't use the parentheses, but that doesn't change the semantics.)
The ugly work-around was

   .... range  -2**31 .. 2**30 + (2**30 - 1);

My question is, "Is this a common 'feature'?"  (Since so many people have
quoted the same example, I presume the answer is 'no')"



First of all let's talk Ada 83. In Ada 83:

   type x is range -(2**31) .. ((2**31)-1);

must work (if there is a suitable base type), and cannot raise
constraint error. However

   subtype y is x range -(2**31) .. ((2**31)-1);

is allowed to raise constraint error, although not required to, and notably
the DEC compiler *did* raise constraint error, although most other compilers
did not.

This was a well known source of undesirable non-portability, and so in
Ada 95, the rules about static expressions were modified to require that
all intermediate static expressions be computed without overflow, so the
above subtype declaration CANNOT cause constraint error in Ada 95.

Re: Integer'Size < 32 ?

[Mark A Biggar]

In article <9608081258.AA02749@most> "W. Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:
>But I have a related question: many of the posts on the topic repeated
>the definition
>   .... range -(2**31) .. ((2**31)-1)
>I once used a compiler for which Integer'Size = 32 and which had an
>interesting "feature."  It recognized that the above would fit in 32 bits,
>so it compiled for that size.  Then at run-time, it would (obeying
>the precedence rules) try to compute 2**31 and raise constraint_error.
>(I didn't use the parentheses, but that doesn't change the semantics.)
>The ugly work-around was
>   .... range  -2**31 .. 2**30 + (2**30 - 1);
>My question is, "Is this a common 'feature'?"  (Since so many people have
>quoted the same example, I presume the answer is 'no')

At minimum this is bad quality of implementation, for an Ada 95 compiler this
appears to a compiler bug.  Ada 95 basically used a duck* test for static
expression and requires that they be evaluated at compile time even when they
don't appear in a static context.

*duck test: if it look like a duck, quacks like a duck, walks like a duck...
	etc, then it must be a duck even if you see it wahere no duck has
	ever apeared before.

--
Mark Biggar
mab@wdl.lmco.com

Re: Integer'Size < 32 ?

[Robert Dewar]

Mark said

"At minimum this is bad quality of implementation, for an Ada 95 compiler this
appears to a compiler bug.  Ada 95 basically used a duck* test for static
expression and requires that they be evaluated at compile time even when they
don't appear in a static context."

Mark's description of the Ada 95 situation is both picturesque and
accurate :-)

By comparison in Ada 83, static expressions were only those that appeared
in syntactic positions requiring static expressions, or perhaps more
accurately, let us say that the exact evaluation rules applied only in
such circumstances.

It is quite unfair to say that what DEC did in Ada 83 was bad quality
implementation. It was quite deliberate. When you are faced with an
implementation dependent feature where you have the choice of accepting
more or fewer valid programs, then you can take one of two attitudes:

1. Accept as much as possible: "Ada code everywhere will port easily to my
   compiler."

2. Accept as little as possible: "Ada code developed on my compiler will
   port easily to other compilers."

Either goal is valid, and without adding zillions of switches to the
compiler you cannot satisfy both (besides satisfying both may add
unacceptable complexity to the compiler).

One situation like this is the choice of elaboration orders. Some compilers
are very friendly in choosing a "good" order of elaboration without the
need for what really are required Elaborate pragmas. Fine, but in practice
that encourages people to write implementation dependent non-portable
programs and they have trouble when they port to other implementations.

Intermetrics has, I believe a switch for this particular case, which seems
like a good idea, basically the settings are choose a good order (one most
likely to succeed), and choose a bad order (one most likely to fail).