Re: Representation clause for enumeratives

[Robert Dewar <dewar@gnat.com>]

In article <LRKg6.1443$y03.158823@news.flash.net>,
  "Ken Garlington" <Ken.Garlington@computer.org> wrote:
> As an aside, here's some fun you can have with the following
package in GNAT
> 3.12p:
>
> : package Big_Enum is
> :
> :    type Object is  (A, B, C);
> :
> :    for Object use(
> :       16#0000_0002#,
> :       16#0000_0004#,
> :       16#8000_0000#
> :       );

That's fine, GNAT will use a 32-bit unsigned representation

> -- But change it to the following, and you get "value not in
>range of type
> 'Standard.Integer'"
> -- (I only changed the first value to -1; it's not in
Standard.Integer? :)
>
>    for Object use(
>       -1,
>       16#7FFF_FFFF#,
>       16#8000_0000#
>       );

No, it's the 2**31 value at the end (16#8000_0000#) that
is not in the range of Standard.Integer. GNAT will use a
32 bit unsigned representation if it can, but if you use
a negative value, you force the use of a signed representation.
Note that biasing is not an option here, since the values must
denote actual representations.

> -- This works fine....
>
>    for Object use(
>       1,
>       2,
>       16#FFFF_FFFF#
>       );

Because a 32-bit unsigned representation can be used

> -- But the following draws the Standard.Integer message...
>
>    for Object use(
>       -16#FFFF_FFFF#,
>       -2,
>       -1
>       );

Because now a 32-bit unsigned representation cannot be used,
so a 32-bit signed representation must be used and the
first value is out of range.

> Tsk - these limited enumeration representation ranges... :)

Reread the above comments and I think things will be clear.
GNAT does its best to satisfy the semantic requirements, while
obeying the size restriction you have placed. It will choose
either a signed or unsigned representation, extending the
number of cases that can be covered, but it cannot fit more
bits into 32 bits than fit :-)

> I wouldn't mind this behavior in a numeric type...
>
> type Hardware_Numeric is range (-16#8000# .. 16#7FFF#) or (
16#0000# ..
> 16#FFFF#);
>
> A : Hardware_Numeric := -1; -- all further literals must be
in range of
> first clause...
> X : Hardware_Numeric := 16#8000#; -- all further literals
must be in range
> of second clause...
>
> Get that into Ada 0Y for me, will ya? :)

Hmmm! I think we will place more emphasis on the smiley here
than the suggestion :-) :-)

But you are confusing issues here, most certainly the idea of
a single type that somehow flips between signed and unsigned
is of course ludicrous.

But here we have separate types, and the RM quite specifically
does NOT specify limitations on the ranges of values that can
be accepted, so the compiler is free to choose any appropriate
underlying representation type.

Yes, it is definitely a non-required, but very useful, behavior
that GNAT will use either signed or unsigned representations
here (after all, the ability to use a signed representation
gives the original questioner what they wanted).

P.S. The one undesirable behavior in GNAT that I see, and will
fix is that the error flag is not clearly placed on the
particular literal that is causing trouble!

>
>


Sent via Deja.com
http://www.deja.com/