Ryan -
I am forwarding this to CFFI-devel and Martin directly (though I'm pretty sure he's subscribed to cffi-devel). Can you please send future messages to cffi-devel? I'm not sure many people read the github mailing list; this issue should get wider visibility. Thanks.
Liam
On Mon, Feb 20, 2012 at 12:02 PM, Ryan Pavlik < reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019@reply.github.com
wrote:
I'm not sure what you mean. It doesn't really matter that a pointer is aggregate or not. The goal is to get at the Nth member of an array-of-something. In the case of scalar C types, you're getting the value; in the case of structs it's far more useful to get a pointer, because you probably only want a single value out of the struct, or to **put a value into the struct**. (The `setf` form works for scalars in the latter case, but not for "member-of-struct-of-index-N"... you most likely want the pointer in these cases.)
It also occurred to me after posting that there is no difference between `(mem-aref ptr '(:pointer (:struct foo)) N)` and just simply `(mem-aref ptr :pointer N)` ... both return a pointer value as if `ptr` is a `void *ptr[k]`.
A struct of more bytes works the same way:
(cffi:defcstruct my-struct (x :long) (y :long) (x :long) (t :long)) ... Old-ref style: ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) aref: #.(SB-SYS:INT-SAP #X7FFFEEFC7FD8) New-ref style: ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) aref: (T 0 Y 0 X 0) New-ref with :pointer style: ptr : #.(SB-SYS:INT-SAP #X7FFFEEFC7FB8) aref: #.(SB-SYS:INT-SAP #X00000000)
Note that on my system, a pointer is 8 bytes, not 4. This is why I initially found the problem, when trying to access an array of points defined by 2 short; each member is 4 bytes, and it was giving offsets to `sizeof(void*)`.
Reply to this email directly or view it on GitHub: https://github.com/cffi/cffi/pull/2#issuecomment-4057418
To answer Ryan's point, I think there should be a different function to get a pointer to an element of an array, called something like mem-aptr. It should work for all element types, not just aggregates.
That allows mem-aref to have "value" semantics for all types. For aggregates, converting to a plist is one possible way to representing it.
On Fri, Feb 24, 2012 at 06:34, Martin Simmons martin@lispworks.com wrote:
To answer Ryan's point, I think there should be a different function to get a pointer to an element of an array, called something like mem-aptr. It should work for all element types, not just aggregates.
That allows mem-aref to have "value" semantics for all types. For aggregates, converting to a plist is one possible way to representing it.
This is actually what I'm doing as an interim workaround. If this was official functionality it would be great. I've been assuming that it was more desirable to have this represented notationally.
For backward compatibility it might be nice for the deprecated (bareword) behavior to retain the old semantics, though.
(Default representation for dereferenced aggregates doesn't matter to me, just that you currently must.)