Re: [CODE][BUG] Exploitable bug in do_flee/do_simple_move

From: Mike Breuer (
Date: 09/11/01

----- Original Message -----
From: "Ronald Fenner Jr" <abbadon@MAC.COM>

> if your saying that your spec_proc does the actual movement I would
> that instead maybe you rethink your implementation of the system. for
> instance allow do_simple_move to handle all the movement for you and after
> it's moved the player check the room they are in and set the bit for the
> item if it's in their inventory. a spec_proc probably is not the best way
> do what you want to  do.

You are describing exactly what I did.  I did not recode the movement
commands, I invoked the existing ones.  The problem is that the return value
of do_simple_move is ambiguous in certain cases.  The comment states that it
returns 1 on success and 0 on failure.  But it always returns 0 on
successful execution of a spec proc that handles one of the movement
commands.  This represents an invalid assumption.

Here is the crude description of the call stack:


As you can see, do_simple_move ends up being called recursively and the
return value of the inner call is lost to the outer call.  This is obviously
a situation that has come up before, because the need_specials_check
argument to do_simple_move exists to prevent an infinite loop in this

Perhaps a better method than putting my code in a spec_proc would be to
build in support for pre and post command procedures that one could
implement.  Then my procedure would only get called AFTER a successful
movement command.  Perhaps I'll pursue that one day, but for now I'll stick
with what I have.  I would be surprised if I'm the only one putting movement
in a spec proc.  Even if I am, I still think the return values in
do_simple_move need to be cleaned up.  At least in the circumstance I have


   | FAQ: |
   | Archives: |

This archive was generated by hypermail 2b30 : 12/06/01 PST