Re: Default_Storage_Pool

["Randy Brukardt" <randy@rrsoftware.com>]

I think the assignment to Janky should raise Program_Error, as it can take 
an object of any lifetime that is *longer* than itself.

RM 3.10.2(13.3/4) says this explicitly "...; accessibility checks ensure 
that this is never deeper than that of the declaration of the stand-alone 
object".

Trying to figure out precisely what check this is talking about is hard, 
however (the AARM is supposed to explain that part as it is claimed to 
follow from other rules -- but it doesn't). I'm not going to try to work 
that out in detail (it's also possible that it is supposed to be illegal).

                                      Randy.

<sbelmont700@gmail.com> wrote in message 
news:86a8a87c-72ca-4718-a2a1-11ee07d66fa8@googlegroups.com...
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
> when it is used). Thus the allocators for the component of type T should 
> use
> Pool_1 regardless of what the Default_Storage_Pool is when the allocator 
> is
> written.
>
> But I'd expect the local anonymous access allocator to use Pool_2. I don't
> see any reason to use some other pool in this case - 13.11.3(6-6.3/4) is
> pretty clear about this, and the rules specifically were designed so that 
> it
> would apply to anonymous access types.
>
> Thus, this appears to be a bug, but I also fail to see any use for it (the
> anonymous access type having to disappear long before anyone can used the
> return value), so I would probably not give it much priority if it was
> reported to me. (Of course, a fuller example could cause me to change my
> mind on that.)
>
>                                     Randy.


Thank you, that was what I thought it should do.  I had no legitimate use 
case, I was just trying to tease out counter-examples to confirm my 
understanding.

I claim no in-depth comprehension, but because of either subsequent bugs or 
perhaps 2012 changes to AATs (or perhaps legitimately), GNAT also takes 
this:

package body O is

   janky : access Integer;

   function F return T is
   begin
      return Result : T do
         declare
            pragma Default_Storage_Pool(Result.pool_2);
            p2 : access Integer;
         begin
            p2 := new integer'(42);
            janky := p2;  --legal?
         end;
      end return;
   end F;
end;

When does janky become a dangling pointer?  Surely if the default pool is 
local to F (because the entire pool goes away after F ends), never if the 
default pool is pool_1 (since it has the same lifetime as janky), and 
'possibly' if it's contained within Result.pool_2 (since it depends on where 
the client has creates the result). GNAT accepts all three variations (well, 
subject 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