On Sun, Apr 25, 2010 at 1:47 PM, Juan Jose Garcia-Ripoll juanjose.garciaripoll@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.