I'm not sure how to address Ryan's case (what I identified as (1)).  I am (effectively) scrapping the changes I have made by redefining defmethod aggregatep ((type foreign-pointer-type)) to give nil, because I found having it T seriously broke GSLL.  I acknowledge your points and Ryan's in his last email but I don't understand pointers and aggregates and structures in C and how they should map to CL enough to understand what to do.  Any thoughts appreciated (Luis? anyone?).<br>

<br>Liam <br>
<br><br><div class="gmail_quote">On Mon, Feb 20, 2012 at 10:38 AM, Martin Simmons <span dir="ltr"><<a href="mailto:martin@lispworks.com">martin@lispworks.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

This looks wrong to me -- a pointer is not an aggregate type.  Also, I think<br>
your test-new-ptr-ref and test-generic-ptr-ref tests are bogus because the<br>
type in mem-aref doesn't match the type of ptr.<br>
<br>
Have you tried it with a struct containing 20 bytes?  Testing it with an array<br>
of two 4 byte structs leads to confusion about the size of a pointer v.s. the<br>
size of one struct v.s. the size of the array.<br>
<br>
In fact, I don't understand what mem-aref is supposed to do for an aggregate<br>
type.  Making it return a pointer to the first byte of the aggregate is<br>
inconsistent with how it treats other types and IMHO leads to the current<br>
confusion.<br>
<br>
__Martin<br>
<div class="im"><br>
<br>
<br>
>>>>> On Sat, 18 Feb 2012 12:53:17 -0500, Liam Healy said:<br>
><br>
> The new syntax is as follows.  If you want the structure itself, use<br>
> (:struct foo).  If you want a pointer to it, use (:pointer (:struct<br>
> foo)).   The latter should be identical to the old style bare struct<br>
> specification, except for the annoying deprecation warning, of course.<br>
><br>
> The issues I can identify, with their resolutions:<br>
><br>
> 1) Using mem-aref with the (:pointer (:struct ...)) spec gives the wrong<br>
> pointer.<br>
><br>
> I have fixed an error which should now return the correct pointer for an<br>
> offset of 0.  For an offset of 1, it returns the base pointer +8 bytes,<br>
> which is not what the old style gives (+ 4 bytes), but it seems to me<br>
> correct, as I understand the index to refer to the number of whole<br>
> structures.   Pull ee90bfd517 and try.<br>
><br>
> 2) The plist form representing the structure is not desirable.<br>
><br>
> You can have any CL representation of the structure you like; you need to<br>
> define a method cffi:translate-from-foreign for your type class.  You are<br>
> getting the default, a plist translation, because no such method is<br>
> defined.   See for example how I translate complex<br>
</div>> numbers<<a href="http://repo.or.cz/w/antik.git/blob/1ee407c69525b84b441f8cf7b48ac590e78bd635:/foreign-array/complex-types.lisp#l50" target="_blank">http://repo.or.cz/w/antik.git/blob/1ee407c69525b84b441f8cf7b48ac590e78bd635:/foreign-array/complex-types.lisp#l50</a>>to<br>


<div><div></div><div class="h5">> CL complex numbers.  You can even return a pointer if you want, but<br>
> this<br>
> probably isn't the specification to use if you want the pointer.<br>
><br>
><br>
> On Mon, Feb 13, 2012 at 10:22 AM, Ryan Pavlik <<br>
> <a href="mailto:reply%2Bi-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019@reply.github.com">reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019@reply.github.com</a><br>
> > wrote:<br>
><br>
> > I've pulled the latest and it appears the semantics have changed for<br>
> > mem-aref, but there is still no way to get the old behavior.  Here is a<br>
> > complete example, though it doesn't use the test system definitions because<br>
> > actual foreign calls and definitions aren't really the problem:<br>
> ><br>
> > ```<br>
> > (asdf:load-system :cffi)<br>
> ><br>
> > (cffi:defcstruct my-struct<br>
> >  (x :short)<br>
> >  (y :short))<br>
> ><br>
> > (defun test-old-ref ()<br>
> >  (declare (notinline cffi:mem-ref cffi:mem-aref))<br>
> >  (cffi:with-foreign-object (ptr '(:struct my-struct) 2)<br>
> >    (format t "~&Old-ref style:~%ptr : ~A~%aref: ~A~%"<br>
> >            ptr (cffi:mem-aref ptr 'my-struct 1))))<br>
> ><br>
> > (defun test-new-ref ()<br>
> >  (cffi:with-foreign-object (ptr '(:struct my-struct) 2)<br>
> >    (format t "~&New-ref style:~%ptr : ~A~%aref: ~A~%"<br>
> >           ptr<br>
> >           (cffi:mem-aref ptr '(:struct my-struct) 1))))<br>
> ><br>
> > (defun test-new-ptr-ref ()<br>
> >  (cffi:with-foreign-object (ptr '(:struct my-struct) 2)<br>
> >    (format t "~&New-ref with :pointer style:~%ptr : ~A~%aref: ~A~%"<br>
> >           ptr<br>
> >           (cffi:mem-aref ptr '(:pointer (:struct my-struct)) 1))))<br>
> ><br>
> > (progn<br>
> >  (test-old-ref)<br>
> >  (test-new-ref)<br>
> >  (test-new-ptr-ref))<br>
> > ```<br>
> ><br>
> > The output I get, sans style-warnings about bare structs:<br>
> ><br>
> > ```<br>
> > Old-ref style:<br>
> > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0)<br>
> > aref: #.(SB-SYS:INT-SAP #X7FFFEEFCFFF4)<br>
> > New-ref style:<br>
> > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0)<br>
> > aref: (Y 0 X 0)<br>
> > New-ref with :pointer style:<br>
> > ptr : #.(SB-SYS:INT-SAP #X7FFFEEFCFFF0)<br>
> > aref: #.(SB-SYS:INT-SAP #X00000000)<br>
> > ```<br>
> ><br>
> > Note that in the first example, with the original semantics, if you<br>
> > mem-aref a pointer to an array of `my-struct`, you get a pointer to the<br>
> > array element.  In the new style, with `(:struct my-struct)`, you get the<br>
> > values parsed into a list, which is not particularly useful; it conses, and<br>
> > you almost certainly have to re-parse a possibly long list for a single<br>
> > element.  In the new style with `:pointer`, it appears to dereference the<br>
> > Nth element in an *array of pointers to my-struct*, which is not at all<br>
> > what we want.<br>
> ><br>
> > The latter differs from the behavior before I updated, which seemed to<br>
> > return a *pointer* to the Nth element in an array-of-pointers.  None of the<br>
> > above are like the old behavior.<br>
> ><br>
> > ---<br>
> > Reply to this email directly or view it on GitHub:<br>
> > <a href="https://github.com/cffi/cffi/pull/2#issuecomment-3941718" target="_blank">https://github.com/cffi/cffi/pull/2#issuecomment-3941718</a><br>
> ><br>
><br>
<br>
</div></div>_______________________________________________<br>
cffi-devel mailing list<br>
<a href="mailto:cffi-devel@common-lisp.net">cffi-devel@common-lisp.net</a><br>
<a href="http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel" target="_blank">http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel</a><br>
</blockquote></div><br>