Re: call_function() and $bf_FOO()

• Date: Sat, 27 Apr 1996 22:25:42 PDT
• From:
  Christopher Unkel <cunkel@us.itd.umich.edu>
• Content-Type: TEXT/PLAIN; charset=US-ASCII
• In-Reply-To: <Pine.LNX.3.91.960427234632.5444A-100000@darkowl.pr.mcs.net>

On Sat, 27 Apr 1996, Don Schwarz wrote:

> On Sat, 27 Apr 1996 slayer@kaiwan.com wrote:
> 
> > >I had thought of that, but I assumed this would be taken care of with
> > >DEFAULT_MAX_STACK_DEPTH the same way regular verb calls are.
> > but then the function doesn't get called at all. Say I had a #0:"bf_fileread
> > bf_fileextract bf_filegrep [...]" and had this:
> > 
> > [...]
> > return call_function(verb[4..$],@args);
> > endif
> > 
> > Yeah, I know this doesn't do permissions checks, but you get the idea,
> > anyway the builtin will never get called since it'll keep calling itself
> > over and over again.
> > 
> So?   If this happens, it obviously means something was programmed
> incorrectly and should raise an E_MAXREC.  What else could it do?

I think that people are missing something.  Of course, I could be wrong, 
but...

Take the ridiculous code
#0:bf_listappend tnt rxd
notify(#2, "in bf_listappend");
set_task_perms(caller_perms());
return call_function("listappend", @args);

This code *will not* recurse infinitely for the same reason that the same 
code except with
return listappend(@args);
won't.  Because the calling verb is on #0, the real builtin is called 
instead of the wrapper.  And, yes, I tried it; the notify is in there to 
convince myself that I was doing everything right.


  --Chris                           cunkel@engin.umich.edu
    ResComp Network Support Technician, Bursley Hall
    "Invisibility is in the eye of the beholder."
    Home Page: http://www-personal.engin.umich.edu/~cunkel/

• Re: call_function() and $bf_FOO()
• From: Don Schwarz <darkowl@darkowl.pr.mcs.net>

• Prev: Re: call_function() and $bf_FOO()
• Next: Re: call_function() and $bf_FOO()
• Index: MOO-cows
• Thread: MOO-cows