* accesibility level problem @ 1999-02-19 0:00 Thomas Handler 1999-02-19 0:00 ` steve quinlan 0 siblings, 1 reply; 12+ messages in thread From: Thomas Handler @ 1999-02-19 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-19 0:00 accesibility level problem Thomas Handler @ 1999-02-19 0:00 ` steve quinlan 1999-02-20 0:00 ` robert_dewar 1999-02-21 0:00 ` Thomas Handler 0 siblings, 2 replies; 12+ messages in thread From: steve quinlan @ 1999-02-19 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-19 0:00 ` steve quinlan @ 1999-02-20 0:00 ` robert_dewar 1999-02-20 0:00 ` Steve Quinlan 1999-03-01 0:00 ` Robert A Duff 1999-02-21 0:00 ` Thomas Handler 1 sibling, 2 replies; 12+ messages in thread From: robert_dewar @ 1999-02-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-20 0:00 ` robert_dewar @ 1999-02-20 0:00 ` Steve Quinlan 1999-02-21 0:00 ` robert_dewar 1999-03-01 0:00 ` Robert A Duff 1 sibling, 1 reply; 12+ messages in thread From: Steve Quinlan @ 1999-02-20 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-20 0:00 ` Steve Quinlan @ 1999-02-21 0:00 ` robert_dewar 0 siblings, 0 replies; 12+ messages in thread From: robert_dewar @ 1999-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-20 0:00 ` robert_dewar 1999-02-20 0:00 ` Steve Quinlan @ 1999-03-01 0:00 ` Robert A Duff 1999-03-02 0:00 ` Thomas Handler 1 sibling, 1 reply; 12+ messages in thread From: Robert A Duff @ 1999-03-01 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-03-01 0:00 ` Robert A Duff @ 1999-03-02 0:00 ` Thomas Handler 0 siblings, 0 replies; 12+ messages in thread From: Thomas Handler @ 1999-03-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-19 0:00 ` steve quinlan 1999-02-20 0:00 ` robert_dewar @ 1999-02-21 0:00 ` Thomas Handler 1999-02-21 0:00 ` Steve Quinlan 1999-02-22 0:00 ` robert_dewar 1 sibling, 2 replies; 12+ messages in thread From: Thomas Handler @ 1999-02-21 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-21 0:00 ` Thomas Handler @ 1999-02-21 0:00 ` Steve Quinlan 1999-02-22 0:00 ` robert_dewar 1999-02-22 0:00 ` robert_dewar 1 sibling, 1 reply; 12+ messages in thread From: Steve Quinlan @ 1999-02-21 0:00 UTC (permalink / raw) 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". ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-21 0:00 ` Steve Quinlan @ 1999-02-22 0:00 ` robert_dewar 0 siblings, 0 replies; 12+ messages in thread From: robert_dewar @ 1999-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-21 0:00 ` Thomas Handler 1999-02-21 0:00 ` Steve Quinlan @ 1999-02-22 0:00 ` robert_dewar 1999-02-22 0:00 ` Thomas Handler 1 sibling, 1 reply; 12+ messages in thread From: robert_dewar @ 1999-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: accesibility level problem 1999-02-22 0:00 ` robert_dewar @ 1999-02-22 0:00 ` Thomas Handler 0 siblings, 0 replies; 12+ messages in thread From: Thomas Handler @ 1999-02-22 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~1999-03-02 0:00 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1999-02-19 0:00 accesibility level problem Thomas Handler 1999-02-19 0:00 ` steve quinlan 1999-02-20 0:00 ` robert_dewar 1999-02-20 0:00 ` Steve Quinlan 1999-02-21 0:00 ` robert_dewar 1999-03-01 0:00 ` Robert A Duff 1999-03-02 0:00 ` Thomas Handler 1999-02-21 0:00 ` Thomas Handler 1999-02-21 0:00 ` Steve Quinlan 1999-02-22 0:00 ` robert_dewar 1999-02-22 0:00 ` robert_dewar 1999-02-22 0:00 ` Thomas Handler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox