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.224.110.68 with SMTP id m4mr4181654qap.2.1358460996311;
        Thu, 17 Jan 2013 14:16:36 -0800 (PST)
X-Received: by 10.49.12.238 with SMTP id b14mr1773069qec.18.1358460996292;
 Thu, 17 Jan 2013 14:16:36 -0800 (PST)
Path: 
 k2ni675qap.0!nntp.google.com!p13no1102687qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 17 Jan 2013 14:16:36 -0800 (PST)
In-Reply-To: <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=192.31.106.35;
 posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j
NNTP-Posting-Host: 192.31.106.35
References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com>
 <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com>
 <ly38xzv86c.fsf@pushface.org>
 <31facfa1-dae9-47c0-b5af-262e31c1d4f9@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <63e09fad-16f0-468d-9d38-7969aaf3abe9@googlegroups.com>
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
From: awdorrin <awdorrin@gmail.com>
Injection-Date: Thu, 17 Jan 2013 22:16:36 +0000
Content-Type: text/plain; charset=ISO-8859-1
Date: 2013-01-17T14:16:36-08:00
List-Id: <comp.lang.ada>


Given the previous definition, the mapping to memory is not what I am expecting. (Which is why I thought I needed the Bit_Order = System.High_Order_First)

Given: TRACK_ID_X at 0 range 0 .. 11;

MyTrkRec.Track_Id_X = 2748; -- 0xabc

Using GDB to debug and print the byte values:
On a little endian system, I get: 0xcb 0x0a
On a big endian system, using the original code, I get: 0xab 0xc0

Now, I expect the numbers to be reordered, due to the endian differences.

This is why I thought the Bit_Order flag was used to fix.
On Intel, using Bit_Order = System.High_Order_First,
I would have expected to see: 0xcb 0xa0