Re: How can one record component be local and another not?

[Jere <jhb.chat@gmail.com>]

On Wednesday, May 6, 2020 at 1:30:58 PM UTC-4, Niklas Holsti wrote:
> On 2020-05-05 20:32, hreba wrote:
> > Ok, with all your hints I came to the following solution:
> > 
> > -- 
> > package Aux is
> >     type Integer_P is access all Integer;
> >     type Rec is limited record
> >        a: aliased Integer;
> >        p: Integer_P;
> >     end record;
> > 
> >     procedure Init (r: access Rec);
> > end Aux;
> > -- 
> > package body Aux is
> >     procedure Init (r: access Rec) is
> >     begin
> >        r.p:= r.a'Access;
> >     end Init;
> > end Aux;
> > -- 
> > with Aux;
> > procedure Test is
> >     r:    aliased Aux.Rec;
> > begin
> >     Aux.Init (r'Access);
> > end Test;
> > -- 
> > 
> <SNIPPED>
> Somewhat surprisingly to me, any call of the form
> "Aux.Init (r'Unchecked_Access)" also works, whether "r" is a 
> library-level object or a local (limited-life) object, even if 
> "Aux.Init" itself uses "'Access" and not "'Unchecked_Access". Apparently 
> the accessibility level provided in the value of Unchecked_Access is 
> such as to make the check succeed, as for a library-level object.
> 
Yeah, RM section 13.10 says it treats it as if the object were declared
at library level for Unchecked_Access

> I also found that a call like "Aux.Init (new Aux.Rec)", which applies 
> "Aux.Init" to a heap-allocated "Rec" object, fails the accessibility 
> check, so this check is really strict. Of course, the heap object can be 
> deallocated at any time, so it may have a short life-time, but that can 
> be done (mainly) by Unchecked_Deallocation, so it involves "unchecked" 
> programming. Hm.
> 
Is that because the heap allocated object is allocated using an
anonymous access type instead of a named access type per chance?
I know anonymous access types have different accessibility level
rules.  It might be setting the accessibility level to the point
of call maybe?