On Sun, May 27, 2012 at 4:48 PM, Luís Oliveira <luis...@gmail.com> wrote:
> On Sun, May 27, 2012 at 9:15 PM, Luís Oliveira <luis...@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
_______________________________________________ cffi-devel mailing list cffi-devel@common-lisp.net http://lists.common-lisp.net/cgi-bin/mailman/listinfo/cffi-devel
