[cffi-devel] uffi compatible library

[Luís Oliveira]

2010/7/13 Gustavo <gugamilare at gmail.com>:
> 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.

IIRC, elephant doesn't work with uffi-compat because it grossly breaks
UFFI's abstractions and mixes sb-alien code with UFFI code.


> 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?

UFFI might not accept saps, I don't remember. But, it should be an
implementation detail if one sticks to the UFFI API.


> 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).

UFFI seems to pass :out along on SBCL/CMUCL/SCL but not other Lisps
(IIUC) and it's not documented.


> 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.

If this is stricly due to Elephant, I'd rather have Elephant itself
fixed. If that's not possible, I'd keep that confined to uffi-compat
at least until we can think of other use cases for an
unwrap-typed-pointer function.

I don't remember if Elephant also assumes that aliens will be
returned; that would be problematic as well.


> 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 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.

That'd be a nice feature indeed. Stephen Compall implemented it at one
point: <http://article.gmane.org/gmane.lisp.cffi.devel/987>. That code
doesn't compile anymore and it's probably not as integrated into
defcfun as you'd wish.

Let us know if you need any help.

Cheers,

-- 
Luís Oliveira
http://r42.eu/~luis/