Re: GNAT 4.4.5 Record Bit_Order Endian issues

["Randy Brukardt" <randy@rrsoftware.com>]

"Stephen Leake" <stephen_leake@stephe-leake.org> wrote in message 
news:854ni9c319.fsf@stephe-leake.org...
> "Randy Brukardt" <randy@rrsoftware.com> writes:
...
>Note the 'otherwise'; that's means the value is R.C'Address - R'Address
>only if position is _not_ specified in a rep clause.

Right, because if it is specified you use that value. But it *always* means 
R.C'Address - R'Address, whether it is specified or not; it's only that the 
*value* comes from the specification if there is one. So I take it you are 
complaining about a misplaced "otherwise".

I'd suggest you write up an Ada-Comment so it gets onto the agenda of the 
ARG to fix next time. (I personally think it is obvious, so I wouldn't worry 
about it, but people differ.)

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

I read that paper three or four times and never understood any of it. The 
discussion of "machine scalars" in the AI and in the RM (and especially 
during the ARG meetings) makes more sense to me than anything in Cohen's 
paper -- and in all honesty, that isn't intuitive, either.

In any case, the Cohen paper is far too long to be used as part of the RM, 
and it surely defies condensation into a few easily understandable 
paragraphs. (If someone can do that, I'd welcome adding it to the AARM, I 
surely couldn't and I tried.)

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

It's referenced from the AI, but as I said, I don't think it helps all that 
much.

                                               Randy.