From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 18 Sep 92 15:41:45 GMT
From: wdl39!mab@ford-wdl1.arpa  (Mark A Biggar)
Subject: Re: Enumerations
Message-ID: <1992Sep18.154145.6086@wdl.loral.com>
List-Id: <comp.lang.ada>

In article <1992Sep17.222636.4782@aio.jsc.nasa.gov> davenpor@sweetpea.jsc.nasa.
gov (Darren Davenport 283-4173) writes:
>In article <9209162110.AA21397@efftoo.boeing.com>, crispen@efftoo.boeing.com (
crispen) writes:
>|> First, the caveat: I *know* that without rep specs all data in Ada is
>|> abstract.
>|> But what I'd like to know is, does anyone know of an Ada compiler
>|> which does not give a machine value of zero for the first element of
>|> an enumeration, one for the second, and so on?
>|> Just idle curiosity, actually, since it came up in the context of a
>|> document I'm writing that's going to say, "Use rep specs for interface
>|> objects and don't trust different compilers to do the same thing".
>You do not need to write that in your document because:
>"The position number of the value of the first listed enumeration literal is
>zero" LRM 3.5.1(4). 

Sorry, but that only says that E'POS(E'FIRST) must be 0, it dosn't say
anything about what bits are actually stored in memory.  Rememeber that even
if there is a rep spec specifing the stored values of the enumeration, the abov
e
identity is still true.  In fact, the only way to determine what bit values
are being used for a given enumeration literal is to use UNCHECKED_CONVERSION
to translate to a suitable integer type.  Now as a Quality Of Implementation
issue I would expect that most Ada compilers, in the absense of a rep spec,
do store the value E'POS(X) for enumeration literal X, but the LRM does not
require it.  I also do not believe that Ada9x gives any relief in this area.

--
Mark Biggar
mab@wdl1.wdl.loral.com