[cffi-devel] cffi-libffi funcall path and :string
Liam Healy
lnp at healy.washington.dc.us
Thu Jun 7 03:14:55 UTC 2012
OK, I've done this in master; there is a new method for foreign-type-alias
in expand-to-foreign-dyn-indirect. Ryan, can you test this version, and,
if possible, post a simple example (whether it worked or not) that we can
add to cffi-tests. Thank you.
Liam
On Mon, May 28, 2012 at 11:33 PM, Liam Healy <lnp at healy.washington.dc.us>wrote:
> On Sun, May 27, 2012 at 4:48 PM, Luís Oliveira <luismbo at gmail.com> wrote:
>
>> On Sun, May 27, 2012 at 9:15 PM, Luís Oliveira <luismbo at gmail.com> wrote:
>> > Did you notice the function lisp-string-to-foreign? Seems like a
>> > cleaner way to implement translate-into-foreign-memory.
>>
>> More importantly, how can you be translating a string without
>> performing allocation in this case? Also, in general,
>> translate-into-foreign-memory for strings should definitely refuse to
>> accept string types without an explicit size. (Which is not
>> implemented yet, IIRC.)
>>
>> In any case, why does Ryan's example need translate-into-foreign-memory?
>
>
> Yeah, the new method is the wrong thing, I need to revert this change.
> When foreign-funcall-form is called and fsbvp=T, it calls translate-objects
> with indirect=T, which in turn calls #'expand-to-foreign-dyn-indirect on
> each of the arguments. When an argument is a foreign-string-type, the
> trouble begins. The foreign string is represented by a pointer, as
> indicated by the (:actual-type :pointer) in the define-foreign-type. All
> libffi really needs is a pointer to the pointer, and there is a method for
> expand-to-foreign-dyn-indirect for foreign-pointer-type, but
> foreign-string-type is not a subclass of foreign-pointer-type.
>
> It seems like the resolution is to define a method for
> expand-to-foreign-dyn-indirect for the foreign-type-alias class that does a
> recursive call using the actual-type. Does that make sense? As a side
> point, expand-to-foreign-dyn has a similar method but it is defined for
> enhanced-typedef (subclass chain: enhanced-typedef < foreign-typedef <
> foreign-type-alias); is there any reason why that method shouldn't be
> defined for foreign-type-alias instead?
>
> Liam
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/cffi-devel/attachments/20120606/732543f8/attachment.html>
More information about the cffi-devel
mailing list