Luís Oliveira wrote:

...

ffi:memory-as is a perfect match for %mem-ref Sure, sure. We would have used it if it were documented. ;-) You didn't read the documentation recently, did you?

darcs diff will produce a short patch. Ah, I used darcs send -uo file.patch instead

It'd be nice if cffi-devel wasn't moderated at all, but I suppose it would get a lot of spam? I have no experience here, but IIRC Kevin Rosenberg or Marco Baringer have very strong opinions on the "subscribe first". I'd just appreciate if the mailing-list descriptions on common-lisp.net would mention that requirement.

However I suppose cffi-clisp's %defcallback should free the previous callback with the same name (maybe this is what you're thinking about). No, I did not mean that.

Something like this? + (let ((cb-fun (get ',name 'clisp-callback-function))) + (when cb-fun (ffi:foreign-free cb-fun))) + (setf (get ',name 'clisp-callback-function) ,cb-var) The comments specifically meant that this would not work, because (foreign-free #.#<FOREIGN-ADDRESS>) -> free(), which is not appropriate, while (foreign-free #.#<FOREIGN-FUNCTION>) lets clisp recognize and free the function.

Cffi currently stores (foreign-address #<foreign-function>) in the plist, thus it cannot free the thing anymore. I haven't investigated what implications storing the #<FOREIGN-FUNCTION> object instead of its address would have on cffi invariants. Another possibility would be to attach a finalizer. But given that cffi callbacks are static only (and thus probably not numerous), I wouldn't bother the GC. There are other situations which create callbacks on the fly, without easy means to free them. For example, each time you pass a Lisp function to a foreign one with type (c-function ...): the Lisp side typically does not see pointer to the callback that gets created.

Btw, I have a question about CLISP's licensing. My question is: does this mean CFFI (the whole CFFI?) would have to be licensed under the GPL? I'm no lawyer either. the question arises from time to time and was even discussed not too long ago for UFFI (in clisp-list or clisp-devel).

My understanding was that there's no problem, as the goal is to provide functionality also available in a great number of Common Lisp implementations.

If so, could these symbols CFFI uses be exported? I'm looking into that.

Regards, Jörg Höhle.