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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: 103376,fd173879a595bde
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.comcast.com!news.comcast.com.POSTED!not-for-mail
NNTP-Posting-Date: Fri, 04 Nov 2005 21:12:57 -0600
From: "Steve" <nospam_steved94@comcast.net>
Newsgroups: comp.lang.ada
References: <slrndmloee.kq0.bogus_addy@tango.mindfuq.org>
 <meKdnXXIJd6tVPfeRVn-vw@comcast.com>
 <slrndmlus8.kq0.bogus_addy@tango.mindfuq.org>
 <TlCaf.1406$uD5.768@newsread3.news.pas.earthlink.net>
Subject: Re: Default rep specs for record types - documented??
Date: Fri, 4 Nov 2005 19:13:14 -0800
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.2180
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180
X-RFC2646: Format=Flowed; Response
Message-ID: <S9OdnXaVctqkvvHeRVn-jQ@comcast.com>
NNTP-Posting-Host: 24.20.111.245
X-Trace: 
 sv3-bFgOcgUFHx+siSzyW4mo1Qp0S5NJdAyxxhxQUG4I/l2I5bCTf+OAZ8XJluaWiFNc+519sJT2o0V5Dke!uhYrCcien3e5Mcp1wZUrxJ49PEWlSBTSNrHR0Cil4rJdnWvlgrGr1OG/wcn594qCIRkqcEeuMpzU
X-Complaints-To: abuse@comcast.net
X-DMCA-Complaints-To: dmca@comcast.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.32
Xref: g2news1.google.com comp.lang.ada:6221
Date: 2005-11-04T19:13:14-08:00
List-Id: <comp.lang.ada>

"Jeffrey R. Carter" <spam@spam.com> wrote in message 
news:TlCaf.1406$uD5.768@newsread3.news.pas.earthlink.net...
> Anonymous Coward wrote:
>
>>   Example: Cohen states that enumerated types are guaranteed to have a
>>   representation that numbers the first element as zero, and increases
>>   sequentially.  Is this not really guaranteed?
>
> It is guaranteed. ARM 13.4 says, "For nonboolean enumeration types, if the 
> coding is not specified for the type, then for each value of the type, the 
> internal code shall be equal to its position number."
>
> ARM 3.5.1 says, "The position number of the value of the first listed 
> enumeration literal is zero; the position number of the value of each 
> subsequent enumeration literal is one more than that of its predecessor in 
> the list."
>
> So, this representation is specified by the language. Therefore, 13.1 
> doesn't apply to enumeration types... [snip]

I disagree with this conclusion.  While I agree that 3.5.1 describes the 
relation between the representation values, it does not define the 
representation.

The number of bits used to represent enumerated values can certainly vary 
between compilers, and can in fact be given a specific size through a 
representation clause (for myenum'size use numBits).

So... if your writing code where representation matters, you need to use 
some form of representation clause for enumeration types as well.

Also:
You can use a representation clause for specific values in an enum.  The 
'succ and 'pred attributes will always give sequential access based on how 
values are declared in the enumeration, but if you use Unchecked_Conversion 
to get at the underlying value, it will match the representation clause.

Steve
(The Duck)

[snip]
>
> -- 
> Jeff Carter
> "Now go away or I shall taunt you a second time."
> Monty Python & the Holy Grail
> 07