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:6184:: with SMTP id s126-v6mr2365677itc.7.1525612541583; Sun, 06 May 2018 06:15:41 -0700 (PDT) X-Received: by 2002:a9d:445c:: with SMTP id f28-v6mr2404000otj.2.1525612541454; Sun, 06 May 2018 06:15:41 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!news.swapon.de!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no1873481itb.0!news-out.google.com!f20-v6ni153itd.0!nntp.google.com!v8-v6no2994159itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 6 May 2018 06:15:41 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=96.247.198.106; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 96.247.198.106 References: <9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com> <9a41b8a3-2ac9-4630-8028-2ba165b0fb0b@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5eec9be4-03ab-4cbc-8de5-0e9697228ab6@googlegroups.com> Subject: Re: Recommendation of safe subset of Ada to use? From: Jere Injection-Date: Sun, 06 May 2018 13:15:41 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:52037 Date: 2018-05-06T06:15:41-07:00 List-Id: On Sunday, May 6, 2018 at 3:43:11 AM UTC-4, Jeffrey R. Carter wrote: > On 05/05/2018 11:32 PM, gorgelo wrote: > >> with Ada.Text_IO; use Ada.Text_IO; > >> > >> procedure jdoodle is > >> type Integer_Access is access all Integer; > >> > >> function Inner(Value : aliased in out Integer) return Integer_Access is > >> begin > >> return Value'Access; > >> end Inner; > >> > >> function Outer return Integer_Access is > >> Value : aliased Integer := 0; > >> begin > >> return Inner(Value); > >> end Outer; > >> > >> Ptr : Integer_Access := Outer; -- !!! Dangling reference > >> begin > >> Put_Line("Hello World"); > >> end jdoodle; > > This seems to violate ARM 3.10.2(29): the accessibility level of Value (the > object passed by reference to Inner) is deeper than that of the access type > Integer_Access. I cannot find an exception to this for aliased parameters. > > -- > Jeff Carter > "It is the German who is so uncourteous to his verbs." > A Scandal in Bohemia > 122 How would you interpret 3.10.2 (7/4)? It just says it doesn't have the same accessibility level as the master. I haven't found anything to suggest what the accessibility level should be at that point. I'll admit, I haven't grasped what the full meaning is. 3.10.2 (7/4): An entity or view defined by a declaration and created as part of its elaboration has the same accessibility level as the innermost master of the declaration except in the cases of renaming and derived access types described below. Other than for an explicitly aliased parameter of a function or generic function, a formal parameter of a callable entity has the same accessibility level as the master representing the invocation of the entity. The other question is what is the purpose of the aliased keyword for function parameters? My impression from reading emails here and some of the rationale was that it was so they could more easily take access values from containers. 3.10.2(29) would seem to go against that since most access types are defined at library level and a lot of containers are declared inside of some function whether that be main (they don't have to be I know, they can be declared at library level as well).