Consider the following definitions
(defcstruct record1 (a :int) (b :int))
(defctype record1-type (:struct record1))
(defcstruct record2a (r (:struct record1)) (c :int))
(defcstruct record2b (r record1-type) (c :int))
record2a_type and record2b_type have identical
representations. However when translating structs using libffi-fsvb
record2b_type will put a pointer in the r field rather than
translating the typedef:
struct record2a foo_a() {
return (struct record2a) { .r = { .a = 1, .b = 2 }, .c = 2 };
}
struct record2a foo_b() {
return (struct record2a) { .r = { .a = 1, .b = 2 }, .c = 2 };
}
(setq $a (cffi:foreign-funcall "foo_a" (:struct record2a)))
;; => (R (B 2 A 1) C 2)
(setq $b (cffi:foreign-funcall "foo_b" (:struct record2b)))
;; => (R #<foreign :VOID 0x1566e70> C 2)
The pointer in the r field is useless, because of its extent.
The immediate fix for this is to define (either in structures or
early-types)
(defmethod translate-from-foreign (value (type foreign-typedef))
(translate-from-foreign value (follow-typedefs)))
so foreign-typedefs always resolve to a structure
But I am not sure. Does this have other ramifications: there seems to
be confusion over how typedefs are resolved (and I do not understand
code for the bare structs and enhanced-typedefs - perhaps I am
expected to go about this problem in some other way? Am I expected to
define methods on translate-from-foreign-memory? or should CFFI always
translate nested aggregates to lisp lists)
