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.36.98.138 with SMTP id d132mr3183684itc.27.1520798023071; Sun, 11 Mar 2018 12:53:43 -0700 (PDT) X-Received: by 10.157.95.23 with SMTP id f23mr323249oti.12.1520798022663; Sun, 11 Mar 2018 12:53:42 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!nntp.giganews.com!peer02.ams1!peer.ams1.xlned.com!news.xlned.com!peer01.am4!peer.am4.highwinds-media.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!r195no1036128itc.0!news-out.google.com!a2-v6ni3441ite.0!nntp.google.com!r195no1036124itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 11 Mar 2018 12:53:42 -0700 (PDT) In-Reply-To: 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 References: <4ab69a18-5766-446c-85c2-14e094199c95@googlegroups.com> <6792fcd7-a25a-417c-b45a-1a17b0168234@googlegroups.com> <5c448ce7-5646-45c5-b221-3d9c884c4d52@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Ada Alternatives to Unrestricted_Access From: Jere Injection-Date: Sun, 11 Mar 2018 19:53:43 +0000 Content-Type: text/plain; charset="UTF-8" X-Received-Bytes: 4176 X-Received-Body-CRC: 4080374874 Xref: reader02.eternal-september.org comp.lang.ada:50932 Date: 2018-03-11T12:53:42-07:00 List-Id: On Sunday, March 11, 2018 at 2:12:48 PM UTC-4, Jeffrey R. Carter wrote: > On 03/11/2018 06:33 PM, Jere wrote: > > It's kind of an odd place to be. You want the tamper checks to ensure > > container safety/correctness, which potentially requires > > Default_Iterator to have mode "in out" but you also don't want to > > restrict the Container to only be used in mutable situations. If > > you want to use a container in non mutable situations, you need > > Default_Iterator to have mode "in". Without tamper checks, everything > > can be mode "in" and happy. > > So you want to bypass one kind of check in order to have another? Is it possible > to tamper with a constant container? > >From a naive view where the client doesn't know the implementation of the container, a client would expect to be able to do: procedure Debug_Print(C : Container) is begin for E of C loop Ada.Text_IO.Put_Line(Element'Image(E)); end loop; end Debug_Print; Which is not possible with Default_Iterator that has mode "in out" You get the earlier mentioned compiler error. Note that here, no tamper check is needed and we are merely accessing a constant view of the container in a constant fashion (forgive the wrong terminology, I don't know the right terminology here). However, additionally, one might want to protect the client from this situation: procedure Nefarious(C : in out Container) is begin for E of C loop if E = Some_Value then C.Delete(E); -- tamper check! end loop; end Nefarious; Here, someone is trying to delete an element during iteration, which should be saved by tamper checks. For reference, the Ada standard containers fulfill both of those scenarios. The original dev team of this code base appears to be mimicking the same methodology. As a note, I'm not particularly thrilled about bypassing any checks. The existing code already does it, and the request is to limit changes to avoid large code overhauls. > I presume this code was written for an earlier version of the language, and now > you want to bolt on this neat new feature of Ada 12. It seems its design and > implementation are not compatible with user-defined iteration. It's all pre-existing code. I don't want to add anything. The iteration was already there. The owner asked to see if I could get rid of some GNAT specific extensions easily. One was the use of Unrestricted_Access, which led me to the original question. They didn't want a major overhaul of the code.