[cffi-devel] ECL specific changes for CFFI

[Luís Oliveira]

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*.


> * Instead of defining NULL-POINTER-P, it would be better to simply reexport
> the symbol living in the "EXT" package. Patch attached.

Pushed.


> * 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?)


> * At the low level ECL has two different foreign function interfaces: one
> used in the interpreter and relying on an external library (libffi) and
> another one, much simpler, using the C compiler. Right now CFFI was only
> using the former unless it was not available. I provide a patch that chooses
> the interface depending on the use of the code: interpreter or compiled.
> (patch attached).

Cool, pushed.


> * Is there the equivalent of launchpad for CFFI? Should I always submit the
> patches to the mailing list? I say this because there are other improvements
> I could forward when I find time.

<http://launchpad.net/cffi> exists. I've been slowly populating it
with my TODO list. The mailing list is probably the best venue for
patches for now, though.

-- 
Luís Oliveira
http://r42.eu/~luis/