Just Launched: You can now import projects and releases from Google Code onto SourceForge
We are excited to release new functionality to enable a 1-click import from Google Code onto the Allura platform on SourceForge. You can import tickets, wikis, source, releases, and more with a few simple steps. Read More
>User beware: fp_valid() etc. are to be called on the
>FOREIGN-POINTER object, which is a slot within the
>FOREIGN-ADDRESS one (pointer indirection, not substructure).
>My extensions to the CLISP FFI (not sure it even in CVS yet)
>provide better access to the VALID bit from Lisp:
>(FFI:MARK-INVALID-FOREIGN foreign-address) and hide the
>FOREIGN-POINTER vs FOREIGN-ADDRESS dichotomy.
I omitted to explain that you must not call MARK-INVALID-FOREIGN on a FOREIGN-ADDRESS object returned via :return-type ffi:c-pointer of a DEF-CALL-OUT function!
Doing so would invalidate the unique foreign session pointer (O(fp_zero) in .d code) that CLISP uses for all usual FOREIGN-ADDRESS/VARIABLE/FUNCTION objects. The FFI would become mostly unusable in your current CLISP session.
You can use MARK-INVALID-FOREIGN or mark_fp_invalid() on pointers you allocated yourself in your module's constructors (via allocate_pointer()).
For example, future CLISP (I think not yet in CVS) will do that for the yet-to-be-polished m/calloc/free interface, and already do so in CVS CLISP for the WITH-FOREIGN-OBJECT WITH-C-VAR macros.
What's important to notice:
All FOREIGN-ADDRESS objects derived from the same FOREIGN-POINTER object share the VALID bit. This can be used for dependency tracking.
For example, with the FFI on AmigaOS, all FOREIGN-FUNCTION objects from a shared library become invalid and thus not callable as soon as the library is closed.
Few month ago, I had ideas about providing a Lisp-level interface to control the dependency between FOREIGN-ADDRESS and FOREIGN-POINTER objects, but I have since forgotten what I had planned ((SET-FOREIGN-BASE x :new)??).