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=-0.4 required=5.0 tests=BAYES_00,FAKE_REPLY_C
	autolearn=ham autolearn_force=no version=3.4.4
X-Google-Thread: a07f3367d7,7b60a2e8329f4e64,start
X-Google-Attributes: gida07f3367d7,public,usenet
X-Google-NewGroupId: yes
X-Google-Language: ENGLISH,UTF8
X-Received: by 10.180.93.134 with SMTP id cu6mr1056257wib.5.1359518277072;
        Tue, 29 Jan 2013 19:57:57 -0800 (PST)
Path: 
 bp2ni5402wib.1!nntp.google.com!feeder1.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!newsfeed.xs4all.nl!newsfeed3.news.xs4all.nl!xs4all!border4.nntp.ams.giganews.com!border2.nntp.ams.giganews.com!nntp.giganews.com!weretis.net!feeder1.news.weretis.net!feeder4.news.weretis.net!news.glorb.com!npeer01.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!news.flashnewsgroups.com-b7.4zTQh5tI3A!not-for-mail
From: Stephen Leake <stephen_leake@stephe-leake.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT 4.4.5 Record Bit_Order Endian issues
Date: Mon, 21 Jan 2013 22:21:32 -0500 (2 minutes, 25 seconds ago)
Message-ID: <854ni9c319.fsf@stephe-leake.org>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (windows-nt)
MIME-Version: 1.0
X-Complaints-To: abuse@flashnewsgroups.com
Organization: FlashNewsgroups.com
X-Trace: 386fa50fe06a4e029e66113159
X-Received-Bytes: 2845
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Date: 2013-01-21T22:21:32-05:00
List-Id: <comp.lang.ada>

"Randy Brukardt" <randy@rrsoftware.com> writes:

> "AdaMagica" <christ-usch.grein@t-online.de> 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).

The full paragraph is:

2/2
R.C'Position

               {AI95-00133-01AI95-00133-01} If the nondefault bit
               ordering applies to the composite type, and if a
               component_clause specifies the placement of C, denotes
               the value given for the position of the
               component_clause; otherwise, denotes the same value as
               R.C'Address - R'Address. The value of this attribute is
               of the type universal_integer.

Note the 'otherwise'; that's means the value is R.C'Address - R'Address
only if position is _not_ specified in a rep clause.

> 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).

Cohen's paper (http://www.ada-auth.org/ai-files/grab_bag/bitorder.pdf)
gives it a clear meaning in that case.

>>> > 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.

Do you think Cohen's paper makes it clear? I gather not. Why not?

If that's too complex to put in the RM, maybe the implementation advice
could include a reference to a copy of Cohen's paper on the adaic
website (somehow I doubt ISO standards allow web references).

-- 
-- Stephe