[cffi-devel] Converting foreign structures with CFFI generic functions

[Liam Healy]

On Fri, Sep 9, 2011 at 4:46 AM,  <Joerg-Cyril.Hoehle at t-systems.com> wrote:
> Hi,
>
> Luís Oliveira wrote:
>>I agree that DEFCSTRUCT* is a lousy name, but DEFCSTRUCT-BY-VALUE
>>is misleading, since there's more going on.
>
> I recommend you look again at CLISP's FFI
> http://www.clisp.org/impnotes/dffi.html
> It is essentially call by value.  It will convert (de-/serialize)
> arbitrarily nested structures to and from Lisp, for instance a full linked
> list of objects given a single pointer (and hang on a circular list...).
> Passing stuff by reference (i.e. using the type (C-POINTER XYZ) was a late addition.

On a quick read, I can't discern how CLISP differentiates
syntactically between call by reference and by value.

>
> Note that automated return by value is not void of problems.  Old APIs use
> structs or &out pointers with flags indicating which fields are valid and
> you better not convert back an invalid char* (or random bits as a float).
> Modern APIs tend to do better here, esp. those that have been influenced
> by remote design thoughts (RPC, network transmission etc.).
>
> The old Haskell/Direct had a domain specific language to express
> such dependencies and I've found myself suggesting some for CLISP
> (e.g. a :guard to prevent dereferencing some slots, as in
> (def-c-fun foobar (:return-type int) ...
> (errorstr (:type c-string) (:out :alloca) (:guard (zerop return)))
> => foobar returns type (values integer (or string null))
>  with integer return value being not 0 => NIL as second value, no string
> (or the converse, I forgot how I originally conceived the guard)
>
> Regards,
>        Jörg Höhle

This is a good point; it would be nice to have some means to prevent
autoconversion.

Liam