Hi, [Sorry for my coming out of the blue after such a long pause]
rpgoldman@sift.info
The somewhat confusing manual materials are (section 8.1 of the ACL manual):
Before accessing a Lisp value from C, it should be registered first. [...] A C function is provided that will return a pointer to the Lisp object given its index.
[...]
If instead one were to pass the registration indices of these Lisp objects, one could readily find their new addresses using these indices following a call-back to Lisp.
I think this clearly implies that the registered object *can* move if the C code ever uses a callback to Lisp. It's *not* pinned in memory.
Scenario Lisp -> C (obtain address) <- Lisp... -> C ;former address can be invalid, ;use index and provided function to obtain new address
One can derive from that that if you hold the address for a long time, including a couple of exchanges between Lisp and C, the original address *can* be stale.
This gives me just another reason against any sort of "with-pointer-to-vector-data" exposed to the outside world. Use that in tight loops inside lowest-level CFFI code (such low-level that no application programmer ever sees it). Don't use that in application code!
As I said long time ago, a good block API is more value to CFFI users than dangerous pinnable vector interfaces. I haven't followed the CFFI evolution this year and don't know if that's been done now.
Regards, Jorg Hohle.