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.198.196 with SMTP id ep4mr3903208qab.3.1358452237841;
        Thu, 17 Jan 2013 11:50:37 -0800 (PST)
X-Received: by 10.49.60.40 with SMTP id e8mr1570764qer.40.1358452237804; Thu,
 17 Jan 2013 11:50:37 -0800 (PST)
Path: 
 k2ni675qap.0!nntp.google.com!p13no1075429qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Thu, 17 Jan 2013 11:50:37 -0800 (PST)
In-Reply-To: <0169b2ea-30b4-45d1-a4d4-c5841e54b9ad@googlegroups.com>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=192.91.171.36;
 posting-account=YkFdLgoAAADpWnfCBA6ZXMWTz2zHNd0j
NNTP-Posting-Host: 192.91.171.36
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: <04cd2ea1-d96f-4b47-93a6-6713f056cbf7@googlegroups.com>
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
From: awdorrin <awdorrin@gmail.com>
Injection-Date: Thu, 17 Jan 2013 19:50:37 +0000
Content-Type: text/plain; charset=ISO-8859-1
Date: 2013-01-17T11:50:37-08:00
List-Id: <comp.lang.ada>

To provide a bit more info from my last post, from the compilation log, when GNAT is processing the Bit_Order clause I see:

info: reverse bit order in machine scalar of length 32
info: little-endian range for component "TRACK_ID_X" is 20 .. 31
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "TRACK_ID_USE_COUNTR_X" is 14 .. 19
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "NORMAL_RAW_DATA_X" is 13 .. 13
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "TRACK_STATUS_X" is 10 .. 12
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "DEAD_RECKONING_FLG_X" is 9 .. 9
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "TRACK_CONVERGENCE_X" is 8 .. 8
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "BLOCKED_TRACK_FLAG_X" is 7 .. 7
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "TRACK_INRFRNCE_ALRT_X" is 6 .. 6
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "MNUVRING_TARGET_FLG_X" is 5 .. 5
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "DESGNATED_TRACK_FLG_X" is 4 .. 4
info: reverse bit order in machine scalar of length 32
info: little-endian range for component "SPAREA" is 0 .. 3

This definition looks correct. For instance the first item in the record, and the first 12 bits of memory, should represent the TRACK_ID_X field.

>From the info messages: 
little-endian range for component "TRACK_ID_X" is 20 .. 31

However, as indicated above, when the 'rep spec' is printed out, this is represented as: TRACK_ID_X at 2 range 4 .. 15;

Quite frustrating! :)

What I'd give for some simple conditional compile directives like there are in C...