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.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,7e29322ee367c19d
X-Google-Attributes: gid103376,public
From: "Werner Pachler" <W.Pachler@mobilkom.at>
Subject: Re: Unchecked_Conversion on different sized types -- problem?
Date: 2000/01/14
Message-ID: <85mqht$6sq$1@fleetstreet.Austria.EU.net>#1/1
X-Deja-AN: 572488756
References: <qXpf4.429$dw3.15200@news.wenet.net>
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
X-Complaints-To: abuse@Austria.EU.net
X-Trace: fleetstreet.Austria.EU.net 947842429 7066 193.154.243.18 (14 Jan 2000
 09:33:49 GMT)
Organization: Customer of EUnet Austria
NNTP-Posting-Date: 14 Jan 2000 09:33:49 GMT
Newsgroups: comp.lang.ada
Date: 2000-01-14T09:33:49+00:00
List-Id: <comp.lang.ada>

I am a little surprised!

As far as i remember UNCHECKED_CONVERSION refused the
unchecked conversion between 2 different sized elements (Ada8x).

Is this new in Ada95?
Is this the new way of "Ada" thinking (to be similar to "C")?

Regards,
Werner

Mike Silva schrieb in Nachricht ...
>To do some prototyping I'm extending Michael Feldman's ANSI screen package
a
>bit, to allow colors, etc, and I ran into a question.  I've enumerated
>various attributes and set the enumerations to the corresponding ANSI
codes,
>and I'm using UC to convert the enumerated types to an Integer, to send via
>Text_IO.Put().  I get a warning (GNAT 3.12p) that the types for the UC have
>different sizes (not surprising), and I'm wondering if UC always does the
>"right" thing here, i.e. zero-extending the smaller enum type when
>converting to an Integer.
>
>Here are some (reduced) relevant code bits:
>
>type T is ( BLACK, WHITE );
>
>for T use ( BLACK => 30, WHITE => 37 );
>
>function T_to_int is new Unchecked_Conversion( T, Integer );
>
>T_val : T := BLACK;
>
>Text_IO.Put( Item => T_to_int( T_val )...
>
>So, is T_to_int going to give me 30, as opposed to, say, all 32 bits
>starting at the address of T_val?  Can somebody tell me where in the LRM it
>talks about this?
>
>(It works "as expected" in this case, but I'm wondering what the rules are)
>
>Also, there's not a simpler way to do this that I'm overlooking, is there?
>
>Mike
>
>
>