[cffi-devel] cffi-libffi funcall path and :string

[Liam Healy]

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/20120528/e821b746/attachment.html>