We need to extend the existing framework to handle the requirement that the callback can update objects passed by pointer, such that the changes are propagated to the original C objects. For instance, a callback receives a pointer to a struct with some strings. The Lisp code updates the strings and we would like the strings to appear back in the C code. The functions which support this sort of thing in the call direction are not quite suitable for this purpose, because that system relies on being able to nail temporary buffers into a stack-allocated rtvec[] which is cleaned up after the FFI call. Anything we write back to a C structure in a FFI callback is is gone out the door; we don't get to clean up any temporary malloced storage. * ffi.c (struct txr_ffi_type): New member out: a virtual fucnction which is like in, but in the opposite direction, and not relying in rtvec. The copy flag argument tells the function whether to just recurse, or whether perform copying, or just recursion. (ffi_ptr_in_out, ffi_ptr_out_out, ffi_struct_out, ffi_array_out): New static functions. (make_ffi_type_pointer): Take an a new parameter for specifying out functions, and store it. (make_ffi_type_struct): Set up an out handler for a struct type or array which needs one. It is needed if any of the element types have an out handler. Basic types don't have out handlers; ptr types do. What if a struct is full of basic types and has no out handler, and is the object of an out pointer? In that case, the logic in ffi_ptr_out_out handles it; it notices that its target type has no out handler, and uses the struct's put function instead to update the underlying C buffer. (ffi_type_compile): Add in functions to ptr types. (ffi_closure_dispatch): After calling the Lisp function, perform a pass of out calls over the parameters, if necessary.