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,FREEMAIL_FROM,
	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: "Vladimir Olensky" <vladimir_olensky@yahoo.com>
Subject: Re: Unchecked_Conversion on different sized types -- problem?
Date: 2000/01/14
Message-ID: <s7skdcr1oj823@corp.supernews.com>#1/1
X-Deja-AN: 572305241
References: <qXpf4.429$dw3.15200@news.wenet.net>
Organization: Posted via Supernews, http://www.supernews.com
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3
Newsgroups: comp.lang.ada
X-Complaints-To: newsabuse@supernews.com
Date: 2000-01-14T00:00:00+00:00
List-Id: <comp.lang.ada>

Unchecked_Conversion gives you a different (type) view of the same object.
So both source and target should be of the same size.

In you case you should have

type T is ( BLACK, WHITE );
for T'Size use 32;                                    -- that was missing in
your code
for T use ( BLACK => 30, WHITE => 37 );


In this case size of T will be equal the size if Integer and your
unchecked coversion will be OK.

Regards,
Vladimir Olensky



Mike Silva wrote in message ...
>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
>
>
>