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.127.135 with SMTP id r129mr4480827itc.48.1519304562834; Thu, 22 Feb 2018 05:02:42 -0800 (PST) X-Received: by 10.157.22.195 with SMTP id s3mr321792ots.13.1519304562705; Thu, 22 Feb 2018 05:02:42 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!feeder.eternal-september.org!border1.nntp.ams1.giganews.com!border2.nntp.ams1.giganews.com!nntp.giganews.com!peer01.ams1!peer.ams1.xlned.com!news.xlned.com!peer02.am4!peer.am4.highwinds-media.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!w142no214797ita.0!news-out.google.com!s63ni733itb.0!nntp.google.com!o66no213823ita.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Thu, 22 Feb 2018 05:02:42 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=137.103.119.68; posting-account=ShYTIAoAAABytvcS76ZrG9GdaV-nXYKy NNTP-Posting-Host: 137.103.119.68 References: <74cfbf22-7082-4a43-aef9-6a55a049fe61@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <86a8a87c-72ca-4718-a2a1-11ee07d66fa8@googlegroups.com> Subject: Re: Default_Storage_Pool From: sbelmont700@gmail.com Injection-Date: Thu, 22 Feb 2018 13:02:42 +0000 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Received-Body-CRC: 3635418812 X-Received-Bytes: 3592 Xref: reader02.eternal-september.org comp.lang.ada:50549 Date: 2018-02-22T05:02:42-08:00 List-Id: On Wednesday, February 21, 2018 at 8:14:03 PM UTC-5, Randy Brukardt wrote: > Default_Storage_Pool only has an effect when an access type is declared (= not=20 > when it is used). Thus the allocators for the component of type T should = use=20 > Pool_1 regardless of what the Default_Storage_Pool is when the allocator = is=20 > written. >=20 > But I'd expect the local anonymous access allocator to use Pool_2. I don'= t=20 > see any reason to use some other pool in this case - 13.11.3(6-6.3/4) is= =20 > pretty clear about this, and the rules specifically were designed so that= it=20 > would apply to anonymous access types. >=20 > Thus, this appears to be a bug, but I also fail to see any use for it (th= e=20 > anonymous access type having to disappear long before anyone can used the= =20 > return value), so I would probably not give it much priority if it was=20 > reported to me. (Of course, a fuller example could cause me to change my= =20 > mind on that.) >=20 > Randy. Thank you, that was what I thought it should do. I had no legitimate use c= ase, I was just trying to tease out counter-examples to confirm my understa= nding. =20 I claim no in-depth comprehension, but because of either subsequent bugs or= perhaps 2012 changes to AATs (or perhaps legitimately), GNAT also takes th= is: package body O is janky : access Integer; =20 function F return T is begin return Result : T do declare pragma Default_Storage_Pool(Result.pool_2); p2 : access Integer; begin p2 :=3D new integer'(42); janky :=3D p2; --legal? end; end return; end F; end; When does janky become a dangling pointer? Surely if the default pool is l= ocal to F (because the entire pool goes away after F ends), never if the de= fault pool is pool_1 (since it has the same lifetime as janky), and 'possib= ly' if it's contained within Result.pool_2 (since it depends on where the c= lient has creates the result). GNAT accepts all three variations (well, sub= ject to the aforementioned bug presumably making case 3 the same as 1) and = raises no exceptions for any of them. Thank you for the continued explanations -sb