Re: eval and exceptions

[Maciek Godek]

Cedric Cellier:

> In the attempt to drastially reduce the work required for a little
> project (a small wargame), I want to use guile to "box" the game engine
> (that is to be) written in C. I also want the players GUI to be
> connected to the game via sockets established by guile (15 lines of
> code, 5s for cut and paste from the guile manual, thank you so much !)

What a coincidence!
I have also be working on a game engine that is to be written :)
More on it later.

> To save even more lines of code, I would like the protocol between
> clients and server to be merely scheme, that is : the client sends some
> scheme command, like, say :
>
> (with-player "Joe" (attack-other-player "Jim"))
>
> and the guile main engine reads it and merely eval-string it.
>
> The problem is : if the client, because of a bug or an
> eroneous or malicious user input, sends a string that is not valid
> scheme, the whole guile engine stops.

If the user is malicious you can have much more serious problems,
like user sending "((lambda(x)(x x))(lambda(x)(x x))" (so the operation
never returns), or "(system \"rm -rf .\")". The latter can be avoided by
simply removing the "system" function, but you have to be cautious.

> I would like to be able to catch those parsing errors out of the eval
> and simply send back an error message to the faulty client, instead of
> having the whole server to stop.
>
> Is there a way to do this, or can you point me toward a better way to
> achieve my goal ? I must confess I'm new to guile and to scheme, and
> have not been deep into the manual yet.

Well, you can call your "eval-string" inside a catch, for example:
(catch #t (lambda()(eval-string packet)) (lambda (key . args) #f))
it should work (refer to the manual for details -- in the third argument
you provide an exception handler, so instead of writing #f you can
send the error back to the client; likewise, the first argument is the
key that can be used to store the client info used by the handler)

I've been trying to address this problem by implementing a network
oriented object system. I'm still working on it and it's still far from
completion, but if you're interested, you can find the specification
in this list's archives:
http://lists.gnu.org/archive/html/guile-user/2008-07/msg00094.html

I think it's more sensible to restrict the protocol to allow
only certain functions to be remotely called -- rather than arbitrary
expressions (this way, some computation can be shifted to the
client more easily and you get a better design)

Either way, this can't be done in 5 seconds :)

Regards
M.