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.66.78.70 with SMTP id z6mr2060313paw.5.1358654369000;
        Sat, 19 Jan 2013 19:59:29 -0800 (PST)
Path: 
 s9ni7514pbb.0!nntp.google.com!npeer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin.stu.neva.ru!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: Wed, 16 Jan 2013 10:44:10 +0000
Organization: A noiseless patient Spider
Message-ID: <lyfw21v24l.fsf@pushface.org>
References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com>
	<85hamiulsn.fsf@stephe-leake.org>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="585248293da7adcafb924c79c19cf5ec";
	logging-data="7930"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX18ETsvYLNn8x2iY8Oz6axAC+NVPNYNFrzw="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:U8dcP6UVOzio1ZbRISIFhI07y74=
	sha1:siiV3fqP2wq/NwOrx2CnkHo71FQ=
X-Received-Bytes: 3006
Content-Type: text/plain
Date: 2013-01-16T10:44:10+00:00
List-Id: <comp.lang.ada>

Stephen Leake <stephen_leake@stephe-leake.org> writes:

> awdorrin <awdorrin@gmail.com> writes:
>
>> I have a record with specification definition that starts, using big endian notation, with:
>>
>> for TRACK_RECORD_TYPE use
>>  record
>>   TRACK_ID at 0 range 0 .. 11;
>>   TRACK_ID_CNT at 1 range 4 .. 9;
>>    ...
>>
>>
>> The meaning being that the first 12 bits hold a track id and the next
>> 6 bits hold the Count value.
>
> If you are allocating consecutive  bits, then do this:
>
> for TRACK_RECORD_TYPE use
>    record
>      TRACK_ID     at 0 range  0 .. 11;
>      TRACK_ID_CNT at 0 range 12 .. 17;
>      ...

I don't see why this makes a difference? It certainly affects how GNAT
behaves, though I have to say it looks buggy to me. 

OP's way:

awdorrin.ads:13:26: info: reverse bit order in machine scalar of length 16
awdorrin.ads:13:26: info: little-endian range for component "Track_Id" is 4 .. 15
awdorrin.ads:15:06: component "Track_Id_Cnt" overlaps "Track_Id" at line 13
awdorrin.ads:15:30: info: reverse bit order in machine scalar of length 16
awdorrin.ads:15:30: info: little-endian range for component "Track_Id_Cnt" is 6 .. 11
gnatmake: "awdorrin.ads" compilation error

Your way:

awdorrin.ads:13:26: info: reverse bit order in machine scalar of length 32
awdorrin.ads:13:26: info: little-endian range for component "Track_Id" is 20 .. 31
awdorrin.ads:14:30: info: reverse bit order in machine scalar of length 32
awdorrin.ads:14:30: info: little-endian range for component "Track_Id_Cnt" is 14 .. 19

Representation information for unit Awdorrin (spec)
---------------------------------------------------

for Track_Record_Type'Size use 32;
for Track_Record_Type'Alignment use 4;
for Track_Record_Type use record
   Track_Id     at 2 range  4 .. 15;
   Track_Id_Cnt at 1 range  6 .. 11;
end record;