"David" == David Lichteblau david@lichteblau.com writes:
David> Quoting rpgoldman@sift.info (rpgoldman@sift.info): >> a pointer for the C code to use, the important thing is to >> avoid having the lisp gc move the byte vector around, which is >> accomplished by the use of register-lisp-value.
David> Are you sure? I believe r-l-v just returns an integer David> index into a global table that can later be used to David> retrieve the object again. That keeps it from being David> garbage collected, but not from movement in memory.
No, I'm not sure!
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. When a Lisp value is registered, an index is returned as a `handle' on the Lisp object. A C function is provided that will return a pointer to the Lisp object given its index. This is preferable to passing addresses of Lisp objects to C functions, since Lisp objects will generally move with each garbage collection. If a garbage collection is triggered from C code - by calling back from C to Lisp - the addresses of Lisp objects originally passed to the C function from Lisp may become invalid. And since one will have lost one's only handle on these Lisp objects, their addresses, there will be no way to find their new addresses. 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.
....
Note that when one passes Lisp values to foreign functions that have been declared using def-foreign-call, most Lisp data types are converted to corresponding C data types automatically. When one obtains Lisp values by calling lisp_value(), the conversion must be performed explicitly by the foreign code."
I read this as saying:
1. I should register the lisp value so that it doesn't get mangled by garbage collection.
2. The use of def-foreign-call means that the indexing stuff will be handled automagically.
Either or both of these might be wrong.
Best, R