accesibility level problem

accesibility level problem

[Thomas Handler]

Hi!

I've been experimenting with an interface for one of my packages and how
to make it easy usable for the users of the package and ran into an
accessibility level problem.

My packages are as follows (I'm using GNAT):


channeldef.ads:

package ChannelDef is

   type Channel is abstract tagged null record;
   type PChannel is access all Channel'Class;
   type ChannelArray is array(Positive range <>) of PChannel;

   procedure AwaitChannels(Channels : ChannelArray);

end ChannelDef;

##############################

channeldef.adb:

package body ChannelDef is

   procedure AwaitChannels(Channels : ChannelArray) is
   begin
      null;
   end AwaitChannels;

end ChannelDef;

##############################

channeldef-superchannel.ads:

package ChannelDef.SuperChannel is

   type SuperChannel is new Channel with record
      Super : Boolean;
   end record;

end  ChannelDef.SuperChannel;

##############################

and finally the test program:

with ChannelDef, ChannelDef.SuperChannel;
use ChannelDef, ChannelDef.SuperChannel;

procedure Testme is
   S1 : aliased ChannelDef.SuperChannel.SuperChannel;
   S2 : aliased ChannelDef.SuperChannel.SuperChannel;
begin
   AwaitChannels((S1'Access, S2'Unchecked_Access));
end Testme;

The problem I have now is that I get 

testme.adb:8:19: object has deeper accessibility level than access type

when compiling testme via gnatmake testme. Compiling with GNAT 3.11p
just changes the error message.
Of course S1'Unchecked_Access does the trick.
What I can't understand is that the accessibility level seems to be
bound to the type declaration and not to the actual object and I haven't
found the right place in the RM to point this problem out.
If anyone could help me getting the right direction this would be great.

Thomas Handler

Re: accesibility level problem

[steve quinlan]

My version of GNAT (3.11b) gives a different message :

 Non-local pointer cannot point to local object

 I think this is just standard accessibility rules. The type channelp is
defined at a package level, the object you are aliasing is defined locally
in a subprogram. It has a deeper level than the acces type -- it could go
out of scope, but objects of that access type could still be in scope, and
you could possibly assign the address of the object to a value of the access
type, thus creating the problem of an invalid reference. The accessibility
rules prevent even the possibility of this happening by not allowing
conversion of an access-to-object to a pointer-to-object when the pointer
may outlive the object (I think). So, it's an appropriate case for
unchecked_access.

You'd just want to make sure that in AwaitChannels, you don't save any of
those references in, say, some package body state variable. That could
generate the invalid reference problem.

Re: accesibility level problem

[robert_dewar]

In article <36CDE45C.5B5E04D8@lmco.com>,
  steve quinlan <steven.quinlan@lmco.com> wrote:
> My version of GNAT (3.11b) gives a different message :
>
>  Non-local pointer cannot point to local object


By the way, this is an example of an error message moving
away from the technical RM description. It is our
experience that talking about accessibility levels is
not illuminating to the typical user, and the sections of
the RM describing the accessibility rules are notoriously
complex (ask Bob Duff's opinion, he was their author and
I believe he has said he finds them hard to understand :-)

So we replaced the original message by one that indicates
the underlying rationale, and since we made that change,
we have had no more questions about this error message!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: accesibility level problem

[Steve Quinlan]

robert_dewar@my-dejanews.com wrote:

>  So we replaced the original message by one that indicates
> the underlying rationale, and since we made that change,
> we have had no more questions about this error message!
>

 I didn't notice it at first, but I think Thomas got that error message as
well, since he mentions that compiling with 3.11p just "changed the error
message", though he didn't give the contents of that message. So, here's a
case where he got the new, kinder, gentler GNAT message, and he DID still
have a question, and wanted to be directed to the relevant RM sections,
hard to understand though they may be.

So, change your statistics on this one -- since the change, you have gotten
at least ONE question on it! (couldn't resist that one, Robert).

                           Steve Quinlan

Re: accesibility level problem

[robert_dewar]

In article <36CEEDCC.80E021D2@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> and wanted to be directed to the relevant RM sections,
> hard to understand though they may be.


Actually I had the impression that he simply wanted to
understand why his code was wrong.

Most certainly directing people to the accessibility
section of the RM is a poor idea. If you can understand
this section, don't go to language lawyer school, you
are already more qualified than the author :-)

I don't know if this section had to be so inpenetrable. I
think the problem was that it is difficult to describe the
restrictions at an appropriate high level of semantic
abstraction.

If you think about the underlying implementation (which
means you must know enough to know the general model which
underlies typical implementations of stack based
languages), then you can in fact re-create the rules based
on the understanding of the underlying aim.

By the way, when I talk about input "we" have received, I
mean ACT at report@gnat.com. As a company we do not pay
attention to anything posted on CLA. I am one of the few
people at ACT who follow CLA, but reporting a problem here
or making a suggestion for an enhancement here does not
constitute talking to ACT!


-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: accesibility level problem

[Thomas Handler]

Hi Steve,

steve quinlan wrote:
> 
> My version of GNAT (3.11b) gives a different message :
> 
>  Non-local pointer cannot point to local object
so does mine (3.11p) ;-)

> 
>  I think this is just standard accessibility rules. The type channelp is
> defined at a package level, the object you are aliasing is defined locally
> in a subprogram. It has a deeper level than the acces type -- it could go
> out of scope, but objects of that access type could still be in scope, and
> you could possibly assign the address of the object to a value of the access
Hmm, sounds as if I have missed something though I have read this
chapter more than twice ;-)

> type, thus creating the problem of an invalid reference. The accessibility
> rules prevent even the possibility of this happening by not allowing
> conversion of an access-to-object to a pointer-to-object when the pointer
> may outlive the object (I think). So, it's an appropriate case for
> unchecked_access.
OK, thank you very much for this description!

> 
> You'd just want to make sure that in AwaitChannels, you don't save any of
> those references in, say, some package body state variable. That could
> generate the invalid reference problem.
This explanation makes accessibility rules even more clear for me.

Once again thank you.

Ciao,
  Thomas Handler

Re: accesibility level problem

[Steve Quinlan]

The relevant section is in the discussion of the 'access attribute (I'm guessing
cuz' GNAT won't tell us)

3.10.2(28) :
"The accessibility level of the view shall not be statically deeper than that of
access type A".

Re: accesibility level problem

[robert_dewar]

In article <36D06C0F.32CA8C6B@umundum.vol.at>,
  Thomas Handler <th@umundum.vol.at> wrote:
> This explanation makes accessibility rules even more
> clear for me.


The key point with accessibility rules is to remember that
they are designed to statically make dangling pointers
impossible, making worst case assumptions. If you have a
clear idea of the underlying stack implementation, then
this goal should be sufficient to understand the motivation
behind the accessibility rules (they are a little similar
to the "scope" rules in Algol-68 which had the same goal).

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: accesibility level problem

[robert_dewar]

In article <36D06F1B.9B4ED53B@lmco.com>,
  Steve Quinlan <steven.quinlan@lmco.com> wrote:
> The relevant section is in the discussion of the 'access
attribute (I'm guessing
> cuz' GNAT won't tell us)
>
> 3.10.2(28) :
> "The accessibility level of the view shall not be
> statically deeper than that of access type A".h

Well that of course is the easy and trivial part. Any
understanding of the accessibility rules has this as a
fundamental starting point.

In a sense, if you don't have that rule down, you have
missed the entire point of the accessibility rules, and
certainly the above paragraph is not going to be
illuminating unless you already know and understand what
acessibility checking is all about.

From a lot of experience with accessibility questions, it
is not 3.10.2(28) rule that is the issue, it is the rather
complex rules that assign accessibility levels. Almost
always, the difficulty is not in understanding that the
accessibility levels must be appropriate, but rather in
understanding WHY in some particular case the accessibility
levels are incompatible.

A reference to 3.10.2(28) may satisfy a check off reference
that there be *some* RM reference, but I am afraid that in
the great majority of misunderstandings of this message,
this reference will merely be annoying, and the user will
say "yes, yes of course I know that, but WHY is are the
levels wrong/different ... in this particular case." It
is MUCH harder to give an RM reference that is really
useful in this case.

After all 3.10.2(28) is exactly a formal statement of the
GNAT error message, nothing more or less, so it adds very
little, except to send you off looking up accessibility
levels, which as I have said before is a very difficult
section, requiring a very clear idea of the dynamic and
static scoping rules.

The best advice here in my opinion is still to think about
the underlying rationale. In fact a reference to the
section in the rationale might be a whole lot more useful
than an RM reference here.

If the compiler objects with a message about dynamic
scoping, think about the following: "If this were allowed,
then in the worst case, why could it cause a dangling
pointer? You know that it could cause dangling, because
otherwise it would not be diagnosed. So the trick is to
see WHY dangling could occur, so that you know how to fix
things, usually by moving some declarations from global
to local, or vice versa.




-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own    

Re: accesibility level problem

[Thomas Handler]

Robert and Steve,

once again a great "Thank you" for bringing in some light.

As Robert pointed out, I already knew (after some trials) that the error
message disappears when declaring the access type locally.
Though having read the RM 3.10.2 forth and back several times it was not
clear to me why I got the error message.
Steve's hint with the possibility of 'chaining' the access brought me
back on track! and Robert was right when saying that the pure
Information in the RM doesn't help you out of the dark ;-)

Thomas Handler

Re: accesibility level problem

[Robert A Duff]

robert_dewar@my-dejanews.com writes:

>...It is our
> experience that talking about accessibility levels is
> not illuminating to the typical user, and the sections of
> the RM describing the accessibility rules are notoriously
> complex (ask Bob Duff's opinion, he was their author and
> I believe he has said he finds them hard to understand :-)

True.  We totally rewrote that section several times during the language
design, with different terminology, desperately trying to make it both
correct in detail, and easy to understand.  IMHO, we didn't succeed in
the second part, and I don't know how to do better.

So I agree with Robert that the compiler should say something vague
about the underlying rationale.  You've *got* to understand that
rationale in order to program in Ada or C or anything similar!

I think the original poster wondered why it was all based on the access
type, and not on the object.  The problem is that the object declaration
doesn't contain any information about where the thing points, and we
didn't want to do it all with run-time checks (although Tucker invented
access parameters fairly late in the game, and they allow a limited form
of run-time checking).

- Bob
-- 
Change robert to bob to get my real email address.  Sorry.

Re: accesibility level problem

[Thomas Handler]

Robert A Duff wrote:
> 
Robert,

> I think the original poster wondered why it was all based on the access
> type, and not on the object.  The problem is that the object declaration
> doesn't contain any information about where the thing points, and we
> didn't want to do it all with run-time checks (although Tucker invented
> access parameters fairly late in the game, and they allow a limited form
> of run-time checking).

This is exactly where my problem was buried - I knew I had the
dependance on the access type but it was not clear for me why - I even
wasn't able to read this info the right way fro the ARM...

Thomas Handler