[Chicken-hackers] [PATCH] Avoid segfault when expanding FFI macros

[Peter Bex]

Hi all,

I discovered that running code which contains FFI macro calls through
the interpreter will cause a segfault.  This happens because these
macros call procedures from the compiler directly.

I don't know why this is not an issue in CHICKEN 4; it seems that the
module itself can be imported, but the macros are not defined by it
in the interpreter?  I would really love a clarification of this, so
that we're sure master doesn't need a similar patch.  It calls some
 procedures which are prefixed ##compiler#, so I suppose the same
problem would exist there if one were able to expand these macros in
the interpreter.

I tried to move foreign-type->scrutiny-type from support.scm into
chicken-ffi-syntax.scm, but it turns out the comment is misleading:
foreign-type->scrutiny-type is used in the scrutinizer too, so we
can't simply move it.  Besides, foreign-type->scrutiny-type calls
final-foreign-type, which uses lookup-foreign-type, which consults
foreign-type-table and so on and so on, so if we wanted to move it
we'd have to do a pretty large restructuring (if possible at all).

So instead, I decided it would be better if the macros themselves
would simply raise a syntax error upon expansion.  Alternatively,
we could try to raise an error in chicken.foreign.import.scm when
an attempt is made to load it, but I think the approach of letting
the macros themselves bail out is somewhat cleaner.

A disadvantage of this is that you can't expand the macro in the
interpreter to see what kind of code it generates.  Another approach
would be to stub out the helper functions so they return a fake value,
but that would be even more confusing because the code wouldn't be
representative for the actual code it expands to.

Cheers,
Peter

0001-Avoid-expanding-to-unbound-procedures-in-FFI-macros.patch
Description: Text Data

signature.asc
Description: PGP signature