[Chicken-hackers] [PATCH] Fix for #852

[Peter Bex]

Hi,

Recently a bug was reported which caused a segfault in the interpreter.
It turns out you can get at macro expanders as first-class objects in
the interpreter.  This is unsupported and not useful generally.
The ir-macro and the second module is a red herring; it also happens
with er-macros and when importing foo and invoking bar at the toplevel.

The segfault is caused by the fact that in eval.scm:212 the lookup
procedure might return macro objects straight from the SE (syntactic
environment).  The find-id procedure protects against that by checking
whether the returned object is a symbol, but the rename procedure
doesn't do that.  When the variable itself directly has a
'##core#macro-alias property, this is returned by rename, regardless
of its type (it can be a macro object).

This could be fixed in rename by checking whether the returned property
value is a symbol, but for symmetry with the compiler I decided to check
it after the lookup has returned.  This parallels the check in
compiler.scm:49

I've also added a test.  Sometimes this would segfault but other times
when the stars are aligned in such and such a way, the segfault doesn't
happen and you can actually retrieve the macro expander object itself,
as I showed in #852, in the first comment.

Cheers,
Peter
-- 
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
 is especially attractive, not only because it can be economically
 and scientifically rewarding, but also because it can be an aesthetic
 experience much like composing poetry or music."
                                                        -- Donald Knuth

0001-Do-not-allow-closure-compiler-to-access-macros-as-fi.patch
Description: Text document