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 10.107.181.20 with SMTP id e20mr17544743iof.43.1520453462755;
        Wed, 07 Mar 2018 12:11:02 -0800 (PST)
X-Received: by 10.157.3.237 with SMTP id f100mr1243912otf.6.1520453462222;
 Wed, 07 Mar 2018 12:11:02 -0800 (PST)
Path: 
 eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!feeder.erje.net!1.eu.feeder.erje.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!r195no264428itc.0!news-out.google.com!a2ni1310ite.0!nntp.google.com!r195no264426itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Wed, 7 Mar 2018 12:11:01 -0800 (PST)
Complaints-To: groups-abuse@google.com
Injection-Info: glegroupsg2000goo.googlegroups.com;
 posting-host=173.71.218.250;
 posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf
NNTP-Posting-Host: 173.71.218.250
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <d4363829-f718-48cf-a01d-6986563e632d@googlegroups.com>
Subject: Ada Alternatives to Unrestricted_Access
From: Jere <jhb.chat@gmail.com>
Injection-Date: Wed, 07 Mar 2018 20:11:02 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:50881
Date: 2018-03-07T12:11:01-08:00
List-Id: <comp.lang.ada>

I'm currently updating a generic package that takes a container type
as an input and creates an iterative type around it.  I found quite a
few instances of GNAT's Unrestricted_Access which appear to be
necessary because of the Iterate function's container parameter of
being mode "in" and the iterator needing a non constant access to it
to supply tamper check semantics.  I tried changing the mode to
"in out" but that caused a slew of errors where Iterate was used 
inside other operations that had the Container supplied via "in"
mode parameters.  Changing those other operations doesn't make
sense (and causes other errors later), but I don't like relying
on GNAT's implementation defined attribute if I can help it.

I was able to use System.Address_To_Access_Conversions to 
achieve both compiler happiness and expected runtime execution, but
I am worried this is not legal as it is skirting kind of close
to Address overlays.  In this case the types are identical aside
from one (the Iterate "in" mode parameter) being constant and the
other (the iterators "Container_Access" component) being variable.
However, I am not fully convinced it is (relatively) safe or portable yet.

The gist of the differences being:

   Container_Access => C'Unrestricted_Access

is converted to:

   Container_Access => A2A.To_Pointer(C'Address)

where:
   
   package A2A is new System.Address_To_Access_Conversions(Container);

and the parameter mode of C is defined as:

   function Iterate
            (C : in Container)
             return Iterator_Interfaces.Forward_Iterator'Class;

and the generic formal for Container

   type Container is tagged private;

I'm working with an existing code base, so complete overhaul is 
not a great option.

If it isn't a good idea, are there alternatives?  Since the Container
implementation is unknown in the generic, I wasn't able to get a version
of the Rosen technique to work as an alternative (same constant vs
variable access problem).