[cffi-devel] ECL specific changes for CFFI

Juan Jose Garcia-Ripoll juanjose.garciaripoll at googlemail.com
Mon Apr 26 07:07:44 UTC 2010


On Mon, Apr 26, 2010 at 12:57 AM, Luís Oliveira <luismbo at gmail.com> wrote:

> On Sun, Apr 25, 2010 at 1:47 PM, Juan Jose Garcia-Ripoll
> <juanjose.garciaripoll at googlemail.com> wrote:
> > * The former definition for :long-long types in cffi-ecl.lisp was broken.
> I
> > have agumented ECL with a feature that signals the existence of such a
> type
> > in ECL and include a patch here for CFFI to take that into account.
> (Patch
> > attached)
>
> I've tweaked your patch to use that feature to decide when to push
> cffi-sys::no-long-long to *features*.
>

Please don't. LONG-LONG is not supported by the interpreter backend (libffi)
because it considers it a complex type.  Until I figure out how to use it,
we should still stick with that.

> * Upon reading the CFFI specification it seems that FOREIGN-FREE can only
> > free memory that has been allocated by CFFI. However the test cases in
> > misc-types.lsp do something else, deallocating the output of my_strdup()
> > explicitely.
>
> That was the probably the original intent. Is this problematic for
> ECL? (I'm guessing it's because of the GC?)
>

It is very problematic because ECL allocates and frees foreign memory using
the garbage collector. If the user applies FOREIGN-FREE upon a pointer  that
was NOT created using CFFI, then ECL's garbage collector will choke. The
tests we causing ECL to hang.

Juanjo

-- 
Instituto de Física Fundamental, CSIC
c/ Serrano, 113b, Madrid 28006 (Spain)
http://tream.dreamhosters.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20100426/3a57354c/attachment.html>


More information about the cffi-devel mailing list