[cffi-devel] Next release of CFFI with cffi-libffi

[Liam Healy]

> IMO the change to mem-aref is bad and will break a lot of code. Until
> now the contract of mem-aref was that it received a pointer to an array
> of the referenced type and returned a pointer offset into the array.
> The fact that it now returns a list is a gratuitous change, with no
> utility. If we actually want these semantics(not sure about it), it
> should be mem-aptr to implement them
>
> --
> Stelian Ionescu a.k.a. fe[nl]ix
> Quidquid latine dictum sit, altum videtur.
> http://common-lisp.net/project/iolib
>

The meaning of mem-aref is that returns the object, not a pointer (unless
the array is an array of pointers).  It still does that.  I'm not sure what
you mean by "returns a list" unless it's the conversion of a foreign
structure to a plist, which is the default representation of a foreign
structure.  You can define the appropriate translate method to return any
representation of the structure you like, and mem-aref is still completely
consistent with the previous meaning, that the object (not a pointer) is
returned.  We introduced mem-aptr to mean the value of the pointer (not the
object) is wanted.

The only danger of breakage is that people previously used bare structure
references to mean the pointer (because no other meaning was possible), and
wanted the pointer back from mem-aref.  That is still supported; if you use
the bare structure and mem-aref, you'll get the pointer.  If you use
(:struct foo), you mean you want the structure, and you'll get it (as a
plist or however you defined the translate method).  If you want an array
of pointers, you can specify (:pointer (:struct foo)) or just :pointer, if
you want an array of structures and get a pointer back, you specify
(:struct foo) and use mem-aptr.

The current behavior makes sense and is completely compatible with the
old.  There is no change to mem-aref.

Liam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20120419/41e04304/attachment.html>