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:a24:a048:: with SMTP id
 o69-v6mr1132404ite.39.1539769678031;
        Wed, 17 Oct 2018 02:47:58 -0700 (PDT)
X-Received: by 2002:a9d:3f09:: with SMTP id m9mr452027otc.5.1539769677501;
 Wed, 17 Oct 2018 02:47:57 -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.215.MISMATCH!z5-v6no33935ite.0!news-out.google.com!l70-v6ni80itb.0!nntp.google.com!z5-v6no33930ite.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 17 Oct 2018 02:47:57 -0700 (PDT)
In-Reply-To: <pq6qp0$1nbs$1@gioia.aioe.org>
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=89.20.165.50;
 posting-account=6yLzewoAAABoisbSsCJH1SPMc9UrfXBH
NNTP-Posting-Host: 89.20.165.50
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>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <138eb1d1-dba4-46a3-aaa3-4505750b3384@googlegroups.com>
Subject: Re: Examining individual bytes of an integer
From: briot.emmanuel@gmail.com
Injection-Date: Wed, 17 Oct 2018 09:47:57 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:54615
Date: 2018-10-17T02:47:57-07:00
List-Id: <comp.lang.ada>

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

GNATCOLL has a package GNATCOLL.Storage_Pools.Headers which does some similar
low-level tricks.
When you use this storage pool, it will allocate extra bytes (for a header type that you
provide), before the object'Address.

GNATCOLL uses it for instance to store reference counting information without impacting
the declaration of objects, or changing what their 'Address means.

Emmanuel