Re: DSO-style FFI

[Davis Herring <herring@lanl.gov>]

> Tom> This approach seems very weird to me.
> Tom> I don't understand why it is preferable to a libffi-based FFI.
> Tom> The main difficulty I see is that now you're either promising an
> Tom> internal Emacs ABI -- hard to do -- or you're requiring recompilations
> Tom> whenever Emacs changes -- hard on users.
> 
> Would any kind of FFI help with data formats?  I don't think so, right?
> The foreign function has to take Emacs Lisp_Objects (maybe just strings
> and numbers) and package its return data in a Lisp_Object.  So how do we
> handle that glue with libffi or anything else without promising some
> minimal internal Emacs ABI?

An interface like ctypes from Python would not involve Lisp_Objects on
the other side, but would rather provide a means for a Lisp program to
specify a mapping from its objects (Lisp_Objects, of course) to the C
datatypes appropriate to the interface.  Simple things like "expose my
string as a writable char*" and "copy my integer into an int passed by
value" would suffice for many clients (or many target libraries, which
is much the same thing).  libffi helps to formulate the actual calls
(with all their platform/ABI-dependent nonsense) based on such abstract
descriptions.

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.