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=unavailable autolearn_force=no version=3.4.4
X-Received: by 2002:a02:e43:: with SMTP id 64-v6mr6173194jae.3.1539937687540;
        Fri, 19 Oct 2018 01:28:07 -0700 (PDT)
X-Received: by 2002:aca:eb91:: with SMTP id
 j139-v6mr590147oih.4.1539937687378;
 Fri, 19 Oct 2018 01:28:07 -0700 (PDT)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.gegeweb.eu!gegeweb.org!usenet-fr.net!proxad.net!feeder1-2.proxad.net!209.85.166.216.MISMATCH!x98-v6no30821ita.0!news-out.google.com!l70-v6ni65itb.0!nntp.google.com!z5-v6no30886ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Fri, 19 Oct 2018 01:28:07 -0700 (PDT)
In-Reply-To: <g2tbq4F6gseU1@mid.individual.net>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=2003:c7:83d2:566f:208c:fba:4080:345a;
 posting-account=rmHyLAoAAADSQmMWJF0a_815Fdd96RDf
NNTP-Posting-Host: 2003:c7:83d2:566f:208c:fba:4080:345a
References: <9d90fa3e-f800-4086-bf97-a65474a8140a@googlegroups.com>
 <pq0706$60k$1@dont-email.me> <g2hqooFq0usU1@mid.individual.net>
 <4ddbc9bf-0e2e-466d-8238-d8f709b985e1@googlegroups.com>
 <g2k5fbF9thnU1@mid.individual.net>
 <pq2sm7$in8$1@franka.jacob-sparre.dk>
 <35f53cd9-4979-49b8-a5df-2c1cf0764507@googlegroups.com>
 <pq5out$fu2$1@franka.jacob-sparre.dk>
 <39be8a25-cc06-4db4-9481-7f484077522d@googlegroups.com>
 <pqatam$ukb$1@franka.jacob-sparre.dk> <g2tbq4F6gseU1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0a401e8f-e6a1-4513-b3f0-af1959774d1c@googlegroups.com>
Subject: Re: Examining individual bytes of an integer
From: AdaMagica <christ-usch.grein@t-online.de>
Injection-Date: Fri, 19 Oct 2018 08:28:07 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:54646
Date: 2018-10-19T01:28:07-07:00
List-Id: <comp.lang.ada>

Am Freitag, 19. Oktober 2018 08:27:19 UTC+2 schrieb Niklas Holsti:
> On 18-10-19 00:18 , Randy Brukardt wrote:
> > "AdaMagica" wrote in message
> > news:39be8a25-cc06-4db4-9481-7f484077522d@googlegroups.com...
> > ...
> >> There remains the other statement:
> >> "By reasonable induction  :-)  the second, third, etc. array elements
> >> follow in increasing address order. But not _guaranteed_, I agree."
> >>
> >> I still claim that this has too be true (of course with a grain of salt for
> >> packead arrays).
> >
> > I agree, it would make indexing calculations really expensive if it isn't
> > true. And I don't see a compiler author doing that on purpose.
> 
> Oh, I'm not so sure... Storing by *reverse* index order should not be 
> much more expensive, if at all.

Hm, but what would be the purpose or gain? Just for the fun of it?

> I seem to remember hearing about a 
> Pascal compiler in which record components were stored in reverse 
> lexical declaration order, just because of the way the compiler turned 
> out, or so I understood.

But records are still another kettle of fish (echoing Randy). Ada does not prescribe how the components are allocated - they may be rearranged in any order.