[UFFI-Users] get-slot-value and nested structures

rif rif at MIT.EDU
Thu Sep 9 06:47:29 MDT 2004

Thanks for your response.

You're probably right, but that won't stop me from asking questions to
try to understand.

> rif wrote:
> >I think we might be conflating two issues here:  
> >   Also, if uffi:get-slot-value converts a structure from foreign to
> >   Lisp, then I find it unlikely that (setf (get-slot-value ...))
> >   would do the right thing.
> Be assured that it does TRT. Similarly,
> (SLOT-VALUE obj 'foo) converts (part of) a CLOS structure to a Lisp object (for example a fixnum), yet (SETF (SLOT-VALUE #) 123) obviously does the right thing.
> There's no difference.
> Maybe you're confusing this with
> (let ((x (slot-value/get-slot-value #)))
>   (setf x 123) which does not set the slot.

Going back to the CLOS example, there's a real difference between
primitive types (e.g. fixnums) and structure types.  If foo is itself
a CL structure with a fixnum slot i, then

(let ((x (slot-value obj 'foo)))
  (setf (slot-value x 'i) 123))

modifies not only the "extracted" foo x, but also the original object
obj, in the sense that future calls to (slot-value obj 'foo) will
retrieve the modified foo.

I expect the same principle in UFFI --- if the "object" retrieved by
get-slot-value is not a primitive type, but is an aggregate foreign
type, I'd expect it to stay unconverted, so that modifications to it
are modifying the underlying (nested) foreign object.  Is this
expectation fundamentally incorrect?

> >2.  The difference between (alien i-s) and (alien (* i-s)).  From
> >    reading the docs on get-slot-value, the outer call to
> >    get-slot-value is "expecting" an (alien (* i-s)), but at least one
> >    CMUCL, it's getting an (alien i-s).
> My $0,02 proposal was precisely to provide such a "get address of slot" functionality, providing proper types to functions/macros.
> >    For CMUCL, if I
> >    understand correctly, a backward compatible fix involves either
> >    adding syntax to get-slot-value to say it's not a pointer (an
> >    :object t keyword, perhaps), or adding a different syntax object
> >    to get slots from non-pointer objects.
> My get-slot-ref proposal is fully general, you can get the address of an integer slot if you wish. It corresponds to C's &(ptr->slot). get-slot-value would be limited to primitive types. There's already get-slot-pointer for pointer types.

I must admit to not really understanding get-slot-pointer.  There are
no examples of its use in either the tests or the examples
subdirectory, and on CMUCL, which is the only platform I have
moderately deep FFI familiarity with, get-slot-pointer and
get-slot-value are identical.  

Looking at your proposal again, it seems like get-slot-ref would also
do what I want.  On CMUCL, get-slot-ref would expand into (alien:addr
(get-slot-value #)), and this is efficient.  However, I wonder if your
proposal is backward compatible with existing UFFI-using code?  I
suspect it might not be, in that currently get-slot-value is used for
non-primitive types.  



More information about the UFFI-Users mailing list