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.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,2d56530d3025e324 X-Google-Attributes: gid103376,public From: dennison@telepath.com Subject: Re: Program error from assignment?? Date: 1998/07/22 Message-ID: <6p5c9p$9qs$1@nnrp1.dejanews.com>#1/1 X-Deja-AN: 373898749 References: <6p3070$bvn$1@nnrp1.dejanews.com> <6p4skk$j73$1@nnrp1.dejanews.com> Organization: Deja News - The Leader in Internet Discussion X-Article-Creation-Date: Wed Jul 22 18:50:33 1998 GMT Newsgroups: comp.lang.ada X-Http-User-Agent: Mozilla/4.0 (compatible; MSIE 4.0; Windows NT; Gateway2000) Date: 1998-07-22T00:00:00+00:00 List-Id: In article <6p4skk$j73$1@nnrp1.dejanews.com>, dennison@telepath.com wrote: > So now this turns into an "accessability level" question. The object that is > pointed to is declared in the declaration section of the main routine. It > exists the entire program. I don't understand the exact rules on accessability > levels, but in my book I should *never* fail an accessability check with this > object. The access type is declared in a package spec. OK. There doesn't seem to be much interest in this. But for the benefit of future dejanews surfers, I'll go ahead and explain what I figured out. I tried this with a second compiler with the same result (Program_Error). So it looks like the language does define the main program to be at a lower accessability level than package specs. Personally I find that a bit weird, but I'm guessing the rationale is as follows: My code could, theoretically, pass the new access value for the object into a task (which had also with'ed the package that declares the access type). Then my main procedure where the object is declared could, theoretically, end. The program will continue to hang around as long as the task doesn't end too. The compiler vendor could have, theoretically, decided to pop the stack for the main procedure even though the program isn't quite done yet. I would have figured the more natural implementation is that the tasks (and their main stacks) are declared on the main procedure's stack along with all its variables, but it doesn't HAVE to be done that way. Then the task in question could have tried to dereference the pointer, thereby accessing a location that is not allocated to that variable any longer. It could be nothing, or code, or some other variable in a subprogram on the stack, or anything. Anyway, I found two solutions to this problem. 1 Tell the compiler "trust me, I know what I'm doing" by accessing the object with a 'Unchecked_Access when I pass it in on the access parameter. It seems odd that 'Unchecked_Access has runtime semantincs in downstream code like that, but it does. 2 Move the object declaration into a package spec somewhere. That gives it the exact same accessability level as the type. I like this solution better, even if the package has to be created specially for the job. (package Make_It_Run_Dammit is ...) T.E.D. -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum