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
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!nntp-feed.chiark.greenend.org.uk!ewrotcd!newsfeed.xs3.de!io.xs3.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Examining individual bytes of an integer
Date: Wed, 17 Oct 2018 16:57:06 -0500
Organization: JSA Research & Innovation
Message-ID: <pq8b7i$k1r$1@franka.jacob-sparre.dk>
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>
 <pq4jjh$5ig$1@gioia.aioe.org> <pq5p3k$i3h$1@franka.jacob-sparre.dk>
 <pq6qp0$1nbs$1@gioia.aioe.org>
Injection-Date: Wed, 17 Oct 2018 21:57:07 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk;
 posting-host="rrsoftware.com:24.196.82.226";
	logging-data="20539"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Response
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:54619
Date: 2018-10-17T16:57:06-05:00
List-Id: <comp.lang.ada>

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message 
news:pq6qp0$1nbs$1@gioia.aioe.org...
> On 2018-10-17 00:35, Randy Brukardt wrote:
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in message
>> news:pq4jjh$5ig$1@gioia.aioe.org...
>>> On 2018-10-16 12:18, AdaMagica wrote:
>>>
>>>> OK, I stay corrected. But I still claim that it would be extremely 
>>>> unfair
>>>> of a compiler not to follow this advice (A'Address = A 
>>>> (A'First)'Address
>>>> with increasing addresses for further components).
>>>
>>> It is a real pain when writing storage pools that must do some 
>>> bookkeeping
>>> around allocated objects. There should really be X'Allocation_Address
>>> there in addition.
>>
>> Meaning what?
>
> Meaning the first address of the object, e.g. of the dope of an indefinite 
> array as it was returned by the allocator:
>
>    Allocation_Address := Pointer_To_Object.all'Address - Offset;
>
> Presently the offset to the object beginning must be estimated during 
> run-time.

I see. Janus/Ada allocates descriptors separately from the rest of the 
object (there will be two calls to Allocate in such a case), and the 
descriptor contains a pointer at the data. We did that in large part because 
it's necessary to support slice actuals: in that case, the bounds and data 
location can be different than those for the original object. (And we didn't 
want a lot of different representations, it's hard enough when there are 
just a handful.)

> Another, probably more ugly method is create a fake storage pool with 
> Deallocate storing its address argument without doing actual deallocation. 
> The object's access type is cast to the fake-pool-specific access type. 
> Unchecked_Deallocation called. The stored value is the true address.

Yuk. This is why 'Address returns the descriptor in Janus/Ada. You can 
always get to the data with indexing.

                                    Randy.