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.8 required=5.0 tests=BAYES_00,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,93fa00d728cc528e
X-Google-Attributes: gid103376,public
X-Google-Thread: 1108a1,93fa00d728cc528e
X-Google-Attributes: gid1108a1,public
X-Google-ArrivalTime: 1994-10-17 17:11:30 PST
Newsgroups: comp.lang.ada,comp.object
Path: 
 bga.com!news.sprintlink.net!howland.reston.ans.net!pipex!uunet!noc.near.net!ray.com!news.ray.com!swlvx2!jgv
From: jgv@swl.msd.ray.com (John Volan)
Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger
Date: Mon, 17 Oct 1994 20:52:44 GMT
Message-ID: <1994Oct17.205244.17450@swlvx2.msd.ray.com>
References: <1994Oct12.224944.25566@swlvx2.msd.ray.com>
 <1994Oct17.154812.9104@swlvx2.msd.ray.com> <CxtwGE.6yp@inmet.camb.inmet.com>
Sender: news@swlvx2.msd.ray.com (NEWS USER)
Organization: Raytheon Company, Tewksbury, MA
Xref: bga.com comp.lang.ada:7017 comp.object:7469
Date: 1994-10-17T20:52:44+00:00
List-Id: <comp.lang.ada>

bobduff@dsd.camb.inmet.com (Bob Duff) writes:

>There is no requirement that type Address have the same representation
                                                         ^^^^^^^^^^^^^^
>as an access type.  In fact, there is no requirement that one access
>type have the same representation as another access type.  There are, in
                    ^^^^^^^^^^^^^^
>fact, compilers that take advantage of this.  I believe that GNAT, for
>example, stores access-to-unconstrained-arrray differently from
>access-to-integer.

I guess the question really hinges on the meaning of the word
"representation".  When you say that two access types may be "stored
differently", do you mean that the number of bits used to store an
access type can be different, or do you only mean that the *contents*
of those bits might be interpreted differently?

All I really need is the relatively weak guarantee that all access types
occupy the same number of bits, i.e.:

    A1'Size = A2'Size, for any two access types A1 and A2

(And perhaps this size is the same as System.Address'Size, but I don't
even need that guarantee.)  If it's reasonably portable to assume
that all access types occupy the same number of bits, then we can have
a "dummy" access type act as a "black box" to store the bit-pattern
of any other access type, via Unchecked_Conversion.  In other words,
can we guarantee the following:

    To_A1 (To_A2 (V1)) = V1

where V1 is any value of access type A1, and

    function To_A1 is new Ada.Unchecked_Conversion (A2, A1);   
    function To_A2 is new Ada.Unchecked_Conversion (A1, A2);   

That's all that my Identity package needs.

I do *not* need the much stronger guarantee that the *contents* of an
address value be equivalent to the *contents* of a corresponding
access value, i.e.:

    For any object X of some designated type D:

        X'Access = X'Address

Evidently, Ada makes no such guarantee.  (For instance, X'Access might
be an offset in longwords from the start of some storage pool, while
X'Address might be an offset in storage units from the start of
memory.  Or, if D is an unconstrained array type, X'Address might be
the location where the first component of X resides, whereas X'Access
might be the location where the "dope" of X begins.  I take it that
the possibility of these kinds of variances are the rationale for the
package System.Storage_Units.Address_To_Access_Conversions in
RM9X-13.7.1;5.0.)  

At any rate, this stronger guarantee is *not* a requirement of my
Identity package, whether you go with the System.Address implementation
or the access-to-dummy-type implementation.  All we need is a portable
way to "opaquely" store the bits of an access value.

-- John Volan

--------------------------------------------------------------------------------
--  Me : Person := (Name                => "John Volan",
--                  Company             => "Raytheon Missile Systems Division",
--                  E_Mail_Address      => "jgv@swl.msd.ray.com",
--                  Affiliation         => "Enthusiastic member of Team Ada!",
--                  Humorous_Disclaimer => "These opinions are undefined " &
--                                         "by my employer and therefore " &
--                                         "any use of them would be "     &
--                                         "totally erroneous.");
--------------------------------------------------------------------------------