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: a07f3367d7,7b60a2e8329f4e64 X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,CP1252 X-Received: by 10.224.110.68 with SMTP id m4mr6942295qap.2.1358599691438; Sat, 19 Jan 2013 04:48:11 -0800 (PST) X-Received: by 10.49.116.1 with SMTP id js1mr2711364qeb.19.1358599691308; Sat, 19 Jan 2013 04:48:11 -0800 (PST) Path: k2ni675qap.0!nntp.google.com!p13no1428732qai.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 19 Jan 2013 04:48:11 -0800 (PST) In-Reply-To: <85k3ra2biw.fsf@stephe-leake.org> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=91.7.92.7; posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf NNTP-Posting-Host: 91.7.92.7 References: <20bda3de-b033-4b4e-8298-2ac47701b814@googlegroups.com> <85hamiulsn.fsf@stephe-leake.org> <85bocoqxis.fsf@stephe-leake.org> <9961f0a1-aa2c-47d5-be84-77e495ea2a0f@googlegroups.com> <85a9s64y8u.fsf@stephe-leake.org> <85k3ra2biw.fsf@stephe-leake.org> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9dc6d5fe-3382-44dd-8460-e042bd6b808e@googlegroups.com> Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues From: AdaMagica Injection-Date: Sat, 19 Jan 2013 12:48:11 +0000 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: 2013-01-19T04:48:11-08:00 List-Id: On Saturday, January 19, 2013 2:43:03 AM UTC+1, Stephen Leake wrote: > Robert A Duff writes: > > Stephen Leake writes: > >> component_clause ::=3D > >> component_local_name at position range first_bit .. last_bit; > >> But I could find no definition of "position"! > > The very next paragraph defines the syntax: > > position ::=3D static_expression > That doesn't say "position is the number of storage_units from the start > of the record" (there's probably a better definition in Cohen's paper). > For all I can tell from the ARM, "position" could be a color number, or > the number of angels on the head of a pin! > Then 13.5.2 talks about the Position attribute. > Which just retreives the mysterious "position" number, it doesn't say > what it _means_. > > I agree that the RM is confusing in this area. > > It's partly my fault. :-( > Ok. What paragraphs do we add? (in five years; better late than never :) The AARM helps, but this is of course not a binding standard: 13.5.2(2.a/2) Ramification: {AI95-00133-01} Thus, for the default bit order= , R.C'Position is the offset of C in storage elements from the beginning of= the object, where the first storage element of an object is numbered zero.= R'Address + R.C'Position =3D R.C'Address. For record extensions, the offse= t is not measured from the beginning of the extension part, but from the be= ginning of the whole object, as usual. (2.b) In =93R.C'Address =96 R'Address=94, the "=96" operator is the one in = System.Storage_Elements that takes two Addresses and returns a Storage_Offset. Why isn't this in the RM itself? An oversight?