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.1 required=5.0 tests=BAYES_00, PP_MIME_FAKE_ASCII_TEXT autolearn=no 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 X-Received: by 10.181.13.205 with SMTP id fa13mr3291909wid.3.1358813676202; Mon, 21 Jan 2013 16:14:36 -0800 (PST) MIME-Version: 1.0 Path: i11ni12101wiw.0!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.131.MISMATCH!xlned.com!feeder3.xlned.com!feeder.erje.net!eu.feeder.erje.net!nuzba.szn.dk!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues Date: Mon, 21 Jan 2013 18:14:26 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: 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> <9dc6d5fe-3382-44dd-8460-e042bd6b808e@googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1358813673 20796 69.95.181.76 (22 Jan 2013 00:14:33 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 22 Jan 2013 00:14:33 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Original X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-01-21T18:14:26-06:00 List-Id: "AdaMagica" wrote in message news:9dc6d5fe-3382-44dd-8460-e042bd6b808e@googlegroups.com... On Saturday, January 19, 2013 2:43:03 AM UTC+1, Stephen Leake wrote: ... >> Then 13.5.2 talks about the Position attribute. >> Which just retreives the mysterious "position" number, it doesn't say >> what it _means_. Huh? 13.5.2(2/2) says in part: "denotes Denotes the same value as R.C'Address � R'Address". That makes it pretty clear what it represents (for the Default_Bit_Order). For the non-default bit order, it just is whatever you specify (and that's all we can say, because it *doesn't* have a clear physical meaning - it defines the machine scalars to use, which makes it a totally confusing mess if you try to work the other way). >> > 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 :) I don't think there is anything that would help. We surely tried when we created the non-default bit order stuff. >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 = R.C'Address. For record extensions, the offset is not >measured >from the beginning of the extension part, but from the beginning of the >whole object, >as usual. >(2.b) In �R.C'Address � R'Address�, the "�" 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? It's not necessary, it follows directly from the definition of "-", 'Address, and 'Position as related above, for the default bit order case. In the non-default bit order, (2.a/2) isn't even true, so it wouldn't help to add such a statement in that case. ('Position defines the machine scalars to use in that case, and the meaning defies any simple explanation -- it's roughly the same as the meaning in the default-bit-order case, but not exactly. The RM can never lie.) Randy.