[cffi-devel] [cffi] FSBV (#2)

[Liam Healy]

I have updated the example in tests/struct.lisp,

(defcfun "alloc_pair" (:pointer (:struct struct-pair))
  (a :int)
  (b :int))

and when I call alloc-pair, I get a pointer back:
(alloc-pair 1 2)
#.(SB-SYS:INT-SAP #X00668E70)

I am not sure how you are seeing the problems you describe.  Can you please
send complete example(s) and describe what you see and what you expect?
If you use the definitions already in the test system, that will make it a
little bit easier.  Thank you.

On Wed, Feb 8, 2012 at 2:28 PM, Ryan Pavlik <
reply+i-1614209-ba246666762196459413560690eb7d3a39c7c7ee-838019 at reply.github.com
> wrote:

> I've been using this, and while it works great for by-value, there no
> longer seems to be a way to iterate struct arrays and get pointers back.
>  This is bad, because I _don't_ always want a struct parsed.  Parsing is
> slow and conses a lot.
>
> However, neither `(mem-aref ptr (:pointer (:struct foo)) n)` nor
> `(mem-aref ptr (:struct foo) n)` give the same thing as the function
> `(mem-aref ptr 'foo n)` does.  Additionally, the compiler-macro form sets
> `*PARSE-BARE-STRUCTS-AS-POINTERS*`, so this results in incorrect iteration
> as well.  I know at least a few existing codebases depend on the old
> behavior.
>
> For instance, I have a cstruct `POINT` which consists of two `:short`.
>  The `foreign-type-size` is 4.  However, with the compiler macro:
>
> ```
> (with-foreign-object (ptr 'point 2)
>  (mem-aref ptr 'point 1)) ;; -> ptr+8
> ```
>
> This is identical to using `(mem-aref ptr '(:pointer (:struct point)) 1)`,
> and wrong.  If the *function* gets called with the old parsing style, you
> get `ptr+4`, which is the only way to do so beyond using `mem-ref` and
> `foreign-type-size` manually.  This breaks a lot of existing code.
>
> If I use `(mem-aref ptr '(:struct point) 1)`, I get values returned, not
> pointers, which is no good if I need the pointer itself.
>
> ---
> Reply to this email directly or view it on GitHub:
> https://github.com/cffi/cffi/pull/2#issuecomment-3874222
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20120212/398f951e/attachment.html>