Program error from assignment??

Program error from assignment??

[dennison]

OK. I give up.

I have the following code:

   type User_Interface_Link is access all User_Interface.Instance'Class;

   type Instance is new User_Interface.Instance with record
      Valid         : Boolean := False;
      Backup        : User_Interface_Link;
   end record;
   .
   .
   .
   procedure Set_Backup (Interface : in out Instance;
                         Backup    : access User_Interface.Instance'Class) is
   begin
      Interface.Valid := True;
      Interface.Backup := User_Interface_Link(Backup);
   end Set_Backup;


The problem is that I'm getting a Program_Error on the second assignment at
runtime. What could cause that?

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

Re: Program error from assignment??

[dennison]

In article <6p3070$bvn$1@nnrp1.dejanews.com>,
  dennison@telepath.com wrote:
> OK. I give up.
>
> I have the following code:
.
.
.
> The problem is that I'm getting a Program_Error on the second assignment at
> runtime. What could cause that?

OK. Since everyone seems to be completely speechless :-), here's what I've
found out so far:

Program_Error can happen on this assignment when the accessability level of
the source pointer's object is deeper than that of the target object's type.
That's so I can't keep around a pointer to an object after it goes away. Fair
enough.

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.

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

Re: Program error from assignment??

[David C. Hoos, Sr.]

dennison@telepath.com wrote in message <6p4skk$j73$1@nnrp1.dejanews.com>...
<snip>
>
>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.
>
The probelem with that reasoning is that there is nothing which
distibguishes your "main program" from any other library procedure which
could be called from another "ain" progeam.  Thus, the lifetime of the
object in question is only diring the execution of the subprogram.in which
it is declared.

Hope this helps,

David C. Hoos, Sr.

Re: Program error from assignment??

[Stephen Leake]

dennison@telepath.com writes:

> Program_Error can happen on this assignment when the accessability level of
> the source pointer's object is deeper than that of the target object's type.
> That's so I can't keep around a pointer to an object after it goes away. Fair
> enough.
> 
> 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.
> 
> T.E.D.

The compiler doesn't know that this routine is your main routine, so
it assumes it could be called from some other routine; then the
accessibility check makes sense. (uh oh; is this an advantage for C
"main"? :). 

You have two options:

1) Declare the object in a library level package (I usually call such
a package main_aux.ads or some such).

2) Use 'Unchecked_Access. This situation is pretty much what
Unchecked_Access is for; you are telling the compiler that you are
smarter than it is (well, at least you promise not to use the pointer
after the object goes out of scope :).

-- Stephe

Re: Program error from assignment??

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<6p4skk$j73$1@nnrp1.dejanews.com>...
>In article <6p3070$bvn$1@nnrp1.dejanews.com>,
>  dennison@telepath.com wrote:
>> OK. I give up.
>>
>> I have the following code:
>.
>.
>.
>> The problem is that I'm getting a Program_Error on the second assignment
at
>> runtime. What could cause that?
>
>OK. Since everyone seems to be completely speechless :-), here's what I've
>found out so far:
>
>Program_Error can happen on this assignment when the accessability level of
>the source pointer's object is deeper than that of the target object's
type.
>That's so I can't keep around a pointer to an object after it goes away.
Fair
>enough.
>
>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, you almost got it right. Yes, it is a problem with dynamic accessibility
level.

Now remember, a type declared in a library package is at accessibility level
0, while an object declared in a library *procedure* (even the one used as
the main program) is at accessibility level 1.

Remember that the main program is a regular procedure in Ada. For example, a
library package could declare tasks that would in turn call the main program
as a regular procedure...

--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Program error from assignment??

[dennison]

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

Re: Program error from assignment??

[dennison]

In article <6p556m$e4o$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
> Remember that the main program is a regular procedure in Ada. For example, a
> library package could declare tasks that would in turn call the main program
> as a regular procedure...

(shudder)

You are one sick puppy for even thinking of that!
:-)

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp   Create Your Own Free Member Forum

Re: Program error from assignment??

[dennison]

In article <u7m15dbki.fsf@gsfc.nasa.gov>,
  Stephen Leake <Stephen.Leake@gsfc.nasa.gov> wrote:
> > levels, but in my book I should *never* fail an accessability check with
this
> > object. The access type is declared in a package spec.
...
> The compiler doesn't know that this routine is your main routine, so
> it assumes it could be called from some other routine; then the
> accessibility check makes sense. (uh oh; is this an advantage for C
> "main"? :).

Ahhh. I hadn't thought about the library routine angle. Thanks to you and
Jean- Pierre for pointing that out (and anyone else whose message I haven't
gotten to yet).

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

Re: Program error from assignment??

[Robert Dewar]

<<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.
>>

This is an obvious violation of the accessibility rules, since the package
spec is at a higher accessibility level. You know that it is OK, but there
is no structural guarantee.

Re: Program error from assignment??

[Dale Stanbrough]

"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."



...and don't forget that there is nothing stating that the main procedure
will outlive other parts of the system (e.g. other tasks could continue
to run).

If you don't want the check made, try using pragma suppress.


Dale

Re: Program error from assignment??

[Tucker Taft]

dennison@telepath.com wrote:

: ...
: 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:

The main subprogram is just like any other subprogram in Ada.
It can be recursive, called from multiple tasks, etc.
All subprograms are at a deeper level than the enclosing scope.

And even without weirdness like calling the main subprogram recursively,
it is definitely the case that the program as a whole is not done
just because the main subprogram returns.  Program termination does
not occur until all the library-level tasks terminate.  In fact,
it is possible for the main subprogram's body to be "null" and
have all of the interesting work happen in library-level tasks,
after the main subprogram returns.

: ...
:   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 ...)

This is the right solution.

: T.E.D.

--
-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Burlington, MA  USA

Re: Program error from assignment??

[Robert Dewar]

T.E.D. said

<<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.
>>


no, no. You needn't hypothesize such strange things. Just realize that
there is nothing special about the main program, it is just a procedure
that anyone could call from anywhere.

Re: Program error from assignment??

[Robert Dewar]

T.E.D. said

<<You are one sick puppy for even thinking of that!
:-)
>>

Actually, I have seen more than one example of recursive main programs
in Ada. There is nothing to prevent it, and it is perfectly reasona ble
to structure a program this way if it makes sense.

Re: Program error from assignment??

[dennison]

In article <dewar.901174774@merv>,
  dewar@merv.cs.nyu.edu (Robert Dewar) wrote:
> Actually, I have seen more than one example of recursive main programs
> in Ada. There is nothing to prevent it, and it is perfectly reasona ble
> to structure a program this way if it makes sense.

Well, that last part of the last sentence is a bit of a tautology, so its
tough to disagree. The part I was having trouble with was thinking of a
situation where it would make sense. I can even perhaps see making the main
procedure recursive as you suggest. But having a task started up by the main
procedure call the main procedure itself?? %-(

Hmmm. Thinking about it, that would be sort of a poor-man's "fork()"...perhaps
I'm getting sick too. :-)

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

Re: Program error from assignment??

[Jean-Pierre Rosen]

dennison@telepath.com a �crit dans le message
<6p5j23$ip7$1@nnrp1.dejanews.com>...
>In article <6p556m$e4o$1@platane.wanadoo.fr>,
>  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>> Remember that the main program is a regular procedure in Ada. For
example, a
>> library package could declare tasks that would in turn call the main
program
>> as a regular procedure...
>
>(shudder)
>
>You are one sick puppy for even thinking of that!
>:-)
>

Not at all, think about how Unix starts. Single user mode, then starting
severall tasks that call the main program will turn the system into
multi-user mode...
--
----------------------------------------------------------------------------
                  J-P. Rosen (Rosen.Adalog@wanadoo.fr)
      Visit Adalog's web site at http://perso.wanadoo.fr/adalog

Re: Program error from assignment??

[tedennison]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 704 bytes --]

In article <6p7rhs$9ra$1@platane.wanadoo.fr>,
  "Jean-Pierre Rosen" <rosen.adalog@wanadoo.fr> wrote:
>
> dennison@telepath.com a �crit dans le message
> >(shudder)
>
> Not at all, think about how Unix starts. Single user mode, then starting
> severall tasks that call the main program will turn the system into
> multi-user mode...

I guess that expalins "fork()".

It would still be much clearer to have the main task be some kind of "kernel"
process and have other procedures implement user processes. Of course OS's
rarely strive for clarity.

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