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: 103376,7b60a2e8329f4e64 X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.181.13.205 with SMTP id fa13mr3033740wid.3.1358445853879; Thu, 17 Jan 2013 10:04:13 -0800 (PST) X-Received: by 10.49.24.13 with SMTP id q13mr1483469qef.33.1358445853454; Thu, 17 Jan 2013 10:04:13 -0800 (PST) Path: i11ni15wiw.0!nntp.google.com!m1no5950884wiv.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 17 Jan 2013 10:04:13 -0800 (PST) In-Reply-To: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> 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> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com> Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues From: awdorrin Injection-Date: Thu, 17 Jan 2013 18:04:13 +0000 Content-Type: text/plain; charset=ISO-8859-1 Date: 2013-01-17T10:04:13-08:00 List-Id: So, now on Debian 7 with GNAT 4.6. Current record definition starts with: for MY_RECORD_TYPE'Bit_Order use System.High_Order_First; for MY_RECORD_TYPE use record TRACK_ID_X at 0 range 0 .. 11; TRACK_ID_USE_COUNTR_X at 0 range 12 .. 17; NORMAL_RAW_DATA_X at 0 range 18 .. 18; TRACK_STATUS_X at 0 range 19 .. 21; DEAD_RECKONING_FLG_X at 0 range 22 .. 22; TRACK_CONVERGENCE_X at 0 range 23 .. 23; BLOCKED_TRACK_FLAG_X at 0 range 24 .. 24; TRACK_INRFRNCE_ALRT_X at 0 range 25 .. 25; MNUVRING_TARGET_FLG_X at 0 range 26 .. 26; DESGNATED_TRACK_FLG_X at 0 range 27 .. 27; SPAREA at 0 range 28 .. 31; end record; Within my code, I have something like: MY_TRK_REC.TRACK_ID_X := 1; MY_TRK_REC.TRACK_ID_USE_COUNTR_X :=1; Examining things through GDB: "p MY_TRK_REC.TRACK_ID_X'Address" returns 0xb5cd0cd2 "p MY_TRK_REC.SPAREA'Address" returns 0xb5cd0cd0 The record elements are being laid out backwards in memory, despite the use System.High_Order_First directive. Looking at the rep-spec output from my compile I get: for MY_RECORD_TYPE use record TRACK_ID_X at 2 range 4 .. 15; TRACK_ID_USE_COUNTR_X at 1 range 6 .. 11; NORMAL_RAW_DATA_X at 1 range 5 .. 5; TRACK_STATUS_X at 1 range 2 .. 4; DEAD_RECKONING_FLG_X at 1 range 1 .. 1; TRACK_CONVERGENCE_X at 1 range 0 .. 0; BLOCKED_TRACK_FLAG_X at 0 range 7 .. 7; TRACK_INRFRNCE_ALRT_X at 0 range 6 .. 6; MNUVRING_TARGET_FLG_X at 0 range 5 .. 5; DESGNATED_TRACK_FLG_X at 0 range 4 .. 4; SPAREA at 0 range 0 .. 3; So, despite my earlier post today, I'm back to believing that the GNAT4.6 implementation is buggy. (or not documented clearly)