* 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)
* Instead of defining NULL-POINTER-P, it would be better to simply reexport the symbol living in the "EXT" package. Patch attached. * 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. * 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). * 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. Cheers Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://tream.dreamhosters.com
0001-Proper-support-of-the-long-long-type.patch
Description: Binary data
0002-Do-not-dealloc-with-FOREIGN-FREE-the-strings-returne.patch
Description: Binary data
0003-Instead-of-defining-a-new-null-pointer-p-just-reexpo.patch
Description: Binary data
0004-Teach-CFFI-to-use-C-INLINE-when-producing-compiled-c.patch
Description: Binary data
_______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
