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,start X-Google-Attributes: gid103376,public From: "Mike Silva" Subject: Unchecked_Conversion on different sized types -- problem? Date: 2000/01/13 Message-ID: #1/1 X-Deja-AN: 572233984 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Complaints-To: news@wenet.net X-Trace: news.wenet.net 947792726 206.169.137.33 (Thu, 13 Jan 2000 11:45:26 PST) NNTP-Posting-Date: Thu, 13 Jan 2000 11:45:26 PST Newsgroups: comp.lang.ada Date: 2000-01-13T00:00:00+00:00 List-Id: 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