From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=BAYES_00,MSGID_RANDY autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,c6e6cdf6ff50e684 X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 2001-02-09 22:40:06 PST Path: supernews.google.com!sn-xit-02!supernews.com!news.gv.tsc.tdk.com!newsfeed.berkeley.edu!ucberkeley!nntp2.deja.com!nnrp1.deja.com!not-for-mail From: Robert Dewar Newsgroups: comp.lang.ada Subject: Re: Representation clause for enumeratives Date: Sat, 10 Feb 2001 06:29:54 GMT Organization: Deja.com Message-ID: <962n4v$fmg$1@nnrp1.deja.com> References: <95tqbh$ag7$1@nnrp1.deja.com> NNTP-Posting-Host: 205.232.38.14 X-Article-Creation-Date: Sat Feb 10 06:29:54 2001 GMT X-Http-User-Agent: Mozilla/4.61 [en] (OS/2; U) X-Http-Proxy: 1.0 x60.deja.com:80 (Squid/1.1.22) for client 205.232.38.14 X-MyDeja-Info: XMYDJUIDrobert_dewar Xref: supernews.google.com comp.lang.ada:5092 Date: 2001-02-10T06:29:54+00:00 List-Id: In article , "Ken Garlington" 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/