Re: Unchecked_Conversion on different sized types -- problem?

["Vladimir Olensky" <vladimir_olensky@yahoo.com>]

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
>
>
>