On Fri, Sep 9, 2011 at 4:46 AM, <joerg-cyril.hoe...@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 _______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
