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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: a07f3367d7,7b60a2e8329f4e64 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.224.198.196 with SMTP id ep4mr4076870qab.3.1358458169029; Thu, 17 Jan 2013 13:29:29 -0800 (PST) X-Received: by 10.49.58.167 with SMTP id s7mr1688966qeq.5.1358458168849; Thu, 17 Jan 2013 13:29:28 -0800 (PST) Path: k2ni675qap.0!nntp.google.com!p13no1093743qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 17 Jan 2013 13:29:28 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=192.31.106.34; posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j NNTP-Posting-Host: 192.31.106.34 References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com> Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues From: awdorrin Injection-Date: Thu, 17 Jan 2013 21:29:29 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-01-17T13:29:28-08:00 List-Id: On Thursday, January 17, 2013 3:58:03 PM UTC-5, Simon Wright wrote: > > That is *because of* the use of the Bit_Order clause. > > If you comment-out the Bit_Order clause and do the same, you'll find > that My_Trk_Rec.Track_Id_X'Address is the same as My_Trk_Rec'Address, > and My_Trk_Rec.Sparea'Address is 3 greater. There appears to be something else going on when trying to address outside of bits 0-7. In order to get the record defined correctly, I had to: 1. Remove the Bit_Order = System.High_Order_First 2. Define the record as the following: for TRACK_RECORD_TYPE use record TRACK_ID_X at 0 range 0 .. 11; TRACK_ID_USE_COUNTR_X at 1 range 4 .. 9; NORMAL_RAW_DATA_X at 2 range 2 .. 2; TRACK_STATUS_X at 2 range 3 .. 5; DEAD_RECKONING_FLG_X at 2 range 6 .. 6; TRACK_CONVERGENCE_X at 2 range 7 .. 7; BLOCKED_TRACK_FLAG_X at 3 range 0 .. 0; TRACK_INRFRNCE_ALRT_X at 3 range 1 .. 1; MNUVRING_TARGET_FLG_X at 3 range 2 .. 2; DESGNATED_TRACK_FLG_X at 3 range 3 .. 3; SPAREA at 3 range 4 .. 7; Things do not appear to work out properly when you try to define everything using 'at 0' and ranges 0-31. Maybe I'm missing something and/or just have myself completely confused at this point, but I am not convinced that the record definition will map to the same locations when compiled on a big endian platform.