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.101 with SMTP id p5mr1720644wiy.0.1358654412233;
        Sat, 19 Jan 2013 20:00:12 -0800 (PST)
Path: 
 i11ni8363wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!feed.tweaknews.nl!194.109.133.81.MISMATCH!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin2!goblin.stu.neva.ru!feeder.erje.net!eu.feeder.erje.net!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 21:34:19 +0000
Organization: A noiseless patient Spider
Message-ID: <lybocovmlg.fsf@pushface.org>
References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com>
	<85hamiulsn.fsf@stephe-leake.org> <lyfw21v24l.fsf@pushface.org>
	<4dfa5513-16c1-43ba-9238-cea4c661f237@googlegroups.com>
Mime-Version: 1.0
Injection-Info: mx04.eternal-september.org;
 posting-host="6d11d42385b58e82a68a7c31ea9c32ac";
	logging-data="24094"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX182lys/CXKlFLQO22VscXyyFV6zm9hyWq4="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (darwin)
Cancel-Lock: sha1:xtf+bcC/bv9r8uXLvaICwfEEObk=
	sha1:J/SPcQpXI0WeSVvtHBDcgrhTsbU=
Content-Type: text/plain
Date: 2013-01-16T21:34:19+00:00
List-Id: <comp.lang.ada>

AdaMagica <christ-usch.grein@t-online.de> writes:

>> 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. 
>
> No, this is acording to the RM (I don't feel like looking up the para
> just now).  The model are machine scalars, and the bits are allocated
> by counting the bits inside the scalar.
>
> In this example, the machine scalar is 16 bits.

It's http://www.ada-auth.org/standards/12aarm/html/AA-13-5-1.html#p13.4
- and the problem isn't so much that the components overlap as that the
machine scalars that they're allocated in overlap.

I don't think I'd ever have written

   for Track_Record_Type use record
     Track_Id at 0 range 0 .. 11;
     Track_Id_Cnt at 1 range 4 .. 9;

because it's confusing whichever bit order you use!