comp.lang.ada
 help / color / mirror / Atom feed
From: dennison@telepath.com
Subject: Re: Program error from assignment??
Date: 1998/07/22
Date: 1998-07-22T00:00:00+00:00	[thread overview]
Message-ID: <6p5c9p$9qs$1@nnrp1.dejanews.com> (raw)
In-Reply-To: 6p4skk$j73$1@nnrp1.dejanews.com

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




  reply	other threads:[~1998-07-22  0:00 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-07-21  0:00 Program error from assignment?? dennison
1998-07-22  0:00 ` dennison
1998-07-22  0:00   ` dennison [this message]
1998-07-23  0:00     ` Tucker Taft
1998-07-23  0:00     ` Robert Dewar
1998-07-22  0:00   ` Robert Dewar
1998-07-22  0:00   ` David C. Hoos, Sr.
1998-07-22  0:00   ` Stephen Leake
1998-07-22  0:00     ` dennison
1998-07-22  0:00   ` Jean-Pierre Rosen
1998-07-22  0:00     ` dennison
1998-07-23  0:00       ` Robert Dewar
1998-07-23  0:00         ` dennison
1998-07-23  0:00       ` Jean-Pierre Rosen
1998-07-24  0:00         ` tedennison
1998-07-23  0:00   ` Dale Stanbrough
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox