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.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,a415d3a613d86a4e
X-Google-Attributes: gid103376,public
From: Wes Groleau <wwgrol@pseserv3.fw.hac.com>
Subject: Re: Ada Enumerations
Date: 1997/12/18
Message-ID: <34996F4F.6D74@pseserv3.fw.hac.com>#1/1
X-Deja-AN: 299501079
Content-Transfer-Encoding: 7bit
Sender: usenet@most.fw.hac.com (News Administration)
X-Nntp-Posting-Host: wwgrol
References: <662cs9$b34$1@newman.pcisys.net>
 <663j9f$e1l@mtinsc02.worldnet.att.net> <dewar.881162762@merv>
 <3485D2AE.3F54@hso.link.com> <dewar.881244174@merv>
 <34873053.15FB@hso.link.com>
Content-Type: text/plain; charset=us-ascii
Organization: Hughes Defense Communications
Mime-Version: 1.0
Reply-To: wwgrol@pseserv3.fw.hac.com
Newsgroups: comp.lang.ada
Date: 1997-12-18T00:00:00+00:00
List-Id: <comp.lang.ada>


> > I must say I don't see so much of a problem with Unchecked_Conversion for
> > replacing Enum_Rep unless you have a really hostile compiler. For types
> > like this, Unchecked_Conversion should work as expected in cases where
> > the number of bits of the source and target differs.
> 
> At least you *hope* so; too bad for you if your application
> depends on it and the compiler doesn't do it right, or if
> you need to port to a "hostile" compiler.  There being no
> rule for this in either Ada83 or Ada95 ....

Well, if your situation is that desperate, you could 
follow the rep. clause in the same source file with 

  Enum_Rep : constant array (Enum_Type)
               of Integer_Type_To_Convert_To := (.........);

This is portable--until you change the rep. spec and forget
to change the table! :-)