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:a6b:bc87:: with SMTP id m129-v6mr17833477iof.120.1525555951386; Sat, 05 May 2018 14:32:31 -0700 (PDT) X-Received: by 2002:a9d:4509:: with SMTP id w9-v6mr2237430ote.10.1525555951273; Sat, 05 May 2018 14:32:31 -0700 (PDT) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!tncsrv06.tnetconsulting.net!feeder.erje.net!2.us.feeder.erje.net!feeder.usenetexpress.com!feeder-in1.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!u74-v6no1427301itb.0!news-out.google.com!15-v6ni2859itg.0!nntp.google.com!v8-v6no2544209itc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sat, 5 May 2018 14:32:31 -0700 (PDT) In-Reply-To: <9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2a04:ae04:9408:b600:c58c:2066:a4e5:ed3b; posting-account=-SMKVgoAAAA8u8UnmI_NwOPA-LGqXugp NNTP-Posting-Host: 2a04:ae04:9408:b600:c58c:2066:a4e5:ed3b References: <9839db28-b6c6-44c9-9d36-336a39c12f25@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <9a41b8a3-2ac9-4630-8028-2ba165b0fb0b@googlegroups.com> Subject: Re: Recommendation of safe subset of Ada to use? From: gorgelo@hotmail.com Injection-Date: Sat, 05 May 2018 21:32:31 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:52018 Date: 2018-05-05T14:32:31-07:00 List-Id: G.B. wrote in the other thread the following on this topic: > 1. Dangling references: Keeping a reference to an object past its lifetime > > Ada: > *********************************************** > 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; Anything that can be done to prevent the above effect should be welcome, if it is representative of what the 2012 RM allows. Or is this new *aliased* parameter thing some I-know-what-I-am-doing Ada? So, do explicitly *aliased* parameters indeed break all accessiblity rules of Ada? I noticed that it is mentioned in the RM alongside parameters that are passed by reference already because their type is a by-reference type. I'd expect then, that one would drop *aliased* for those kinds of type, thus 27. with Ada.Text_IO; use Ada.Text_IO; 28. 29. procedure jdoodle2 is 30. type T is tagged 31. record 32. Data : Integer; 33. end record; 34. 35. type T_Access is access all T; 36. 37. function Inner(Value : in out T) return T_Access is 38. begin 39. return Value'Access; | >>> non-local pointer cannot point to local object 40. end Inner; 41. 42. function Outer return T_Access is 43. Value : aliased T := T'(Data => 0); 44. begin 45. return Inner(Value); 46. end Outer; 47. 48. Ptr : T_Access := Outer; 49. begin 50. Put_Line("Hello World"); 51. end jdoodle2; The same dangling pointer effect reappears, however, when I put *aliased* back, for no apparent reason: function Inner(Value : aliased in out T) return T_Access is begin return Value'Access; end Inner;