Bugs for Sorcery are reported here

[bugzilla-daemon AT metalab.unc.edu]

http://bugs.sourcemage.org/show_bug.cgi?id=6392





------- Additional Comments From acedit AT armory.com  2004-06-24 23:33 -------
So this work has done a lot to help spells look a lot simpler but theres
an issue I found the other day that I think is pretty critical with
this code.

We have this problem of spells leaking global variables so they can stay
persistant across CONFIGURE and DEPENDS. Unfortunatly they also stay
persistant across spells in the phase of casting. config_get_option has
this bit of logic to check if the variable is already set and return
0 if so. However as I discovered the other night real_config_query
is rather strict about getting a reasonable value back or it calls exit.

Heres an example
We do CONFIGURE on spell foo which sets a variable XYZ to fork_bomb
since to spell foo, XYZ is a string or something. Then spell bar is
inspected and sorcery runs its CONFIGURE. bar is a new spell and has
never had its config variables touched, bar also has an XYZ variable
which it uses through config_query. Since bar has no previous value
or XYZ the invalid value from spell foo is still floating around.
config_get_option will then look at the value of XYZ, conclude that
it is non-zero in length and proclaim that the variable is defined.
real_config_query looks at that value (fork_bomb) and concludes that
its not "y" or "n" and thus an invalid value, then yells "Wrong value !!!"
and promptly exits.

I think that until we can get all spells to use the persistant variable
api we can not make the assumption that if a variable is set it must be
something valid due to this leaky variable problem. We can however make
the assumption that before we are in any spell file persistant_load was
run and thus any variable previously defined and saved would be set. If
the variable is not listen in the PERSISTANT_VARIABLES list, its value
is not valid (or the caller is trying to mess with us and should know
better).

The more long term goal could be to shield PREPARE/DETAILS/CONFIGURE in
this phase off in a subshell then variables can't leak. Of course we
can only do that once spells stop relying on variables to leak between
CONFIGURE and DEPENDS and use persistant variables.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.