[cffi-devel] uffi compatible library

[Gustavo]

Hello,

As I've noticed, the compatibility layer of cffi to uffi has a couple of
problems. For that reason it does not work with elephant out of the box. I
intend trying to address these problems and send patches afterwards.

I'm using SBCL. It seems to me that one of the problems it that functions
defined with (original) uffi accepts aliens and saps as pointer arguments,
while cffi (and uffi-compat) only work with saps, right? Another problems
seems to be that uffi's def-function accepts :out arguments, unlike cffi's
defcfun. Such arguments are not passed when you call the wrapper function,
the wrapper automatically pass foreign-allocated pointers to the C function
which is supposed to put some value in that pointer. Then the wrapper
function returns the values inserted by the C function as multiple values
(starting from the second value).

I intend to adapt uffi-compat's functions to unwrap aliens into saps. That
is implementation dependent, so I was thinking about putting one function
named unwrap-typed-pointer in cffi-sys and also put an entry in the
documentation for other implementations (that have typed pointers like
SBCL's aliens) to possibly implement this function as well. That function
would only be used in uffi-compat, not in cffi.

Now, about :out arguments, wouldn't it be nice if cffi supports this as
well? Currently many projects have to do this by hand, why not abstract it
away? That would also make elephant portable to cffi more easily. The list
of arguments of
defcfun<http://common-lisp.net/project/cffi/manual/html_node/defcfun.html#defcfun>would
become

arguments ::= { (arg-name arg-type [direction]) }*

where direction could be :in (the default) or :out. In case it's :out, the
argument should not be passed to the function, like in uffi. Other possible
options are :copy and :in-out like sbcl's
define-alien-routine<http://www.sbcl.org/manual/#The-define_002dalien_002droutine-Macro>
.

Any thoughts are appreciated.

Regards,
Gustavo.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20100712/31b74a71/attachment.html>