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 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.180.83.2 with SMTP id m2mr50606wiy.0.1358456283476;
        Thu, 17 Jan 2013 12:58:03 -0800 (PST)
X-FeedAbuse: http://nntpfeed.proxad.net/abuse.pl feeded by 88.191.116.97
Path: 
 o9ni3767wio.1!nntp.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!nntpfeed.proxad.net!dedibox.gegeweb.org!gegeweb.eu!gegeweb.org!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
Date: Thu, 17 Jan 2013 20:58:03 +0000
Organization: A noiseless patient Spider
Message-ID: <ly38xzv86c.fsf@pushface.org>
References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com>
	<0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="6d11d42385b58e82a68a7c31ea9c32ac";
	logging-data="2212"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18gSpp5GZVVDntm6PEUdfIYSRYVj2agK3Y="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:5a+eAQiBgsj3ykTmwfhrULUk2Ac=
	sha1:DQTpTHCmkFveNBRIREosbrN35Pc=
Content-Type: text/plain
Date: 2013-01-17T20:58:03+00:00
List-Id: <comp.lang.ada>

awdorrin <awdorrin@gmail.com> writes:

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

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.