[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Peter Bex
Subject: [Chicken-hackers] [PATCH] Fix for #852
Date: Sat, 19 May 2012 17:53:56 +0200
User-agent: Mutt/


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

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.

"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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]