Attila Lendvai attila@lendvai.name writes:
the c2ffi output contains offset for each field in a struct, which enables us to generate partial bindings where not all struct fields need to have a defined type.
Is this because the user doesn't care about some slots or because the type may not be defined yet? If it's the former, you can just omit the slot, provided you pass the appropriate :size argument to defcstruct so that CFFI know how big the struct is despite missing slots.
my current idea to deal with undefined types is the following:
- (cffi:defctype undefined :char "Used by cffi-c2ffi to mark types that are used in e.g. structs,
but are not defined in the scope of the generation.")
This idea suggests you don't care about the slot, just omit then.
- in a first phase collect all defined and referenced types. (this may be a PITA because i don't know all the ins and outs of C namespaces, e.g. where is it ok to reference a struct by only its name, as opposed to by "struct some-struct", and which namespaces are looked up in naked type references, etc.)
It's only possible to reference a struct with "some_struct" when there's a "typedef struct some_struct some_struct".
- in the emitting phase first emit defctype for each used but not defined type before emitting the definitions themselves
Can't you sort the definitions in topological order? https://en.wikipedia.org/wiki/Topological_sorting
That should ensure definitions would always show up before their uses, right?
- while emitting definitions simplify them compatibly. e.g. the bindings of functions that take a pointer to an undefined type get simplified into a :pointer.
the way cl-autowrap deals with this is that its struct framework doesn't complain for undefined types because it expects :offset for each field.
It also needs to know the size of the struct, right?
maybe defcstruct could be extended in a sane way with something like this?
You know what, we've had a similar discussion before, 8 years ago! :-) http://thread.gmane.org/gmane.lisp.cffi.devel/1116. It might be possible to delay the typing for defcstruct, but it'd be simpler (well, from my point of view) if you handled this during the binding generation.
Attila Lendvai attila@lendvai.name writes:
the c2ffi output contains offset for each field in a struct, which enables us to generate partial bindings where not all struct fields need to have a defined type.
and on this note, where can i find info/examples on bitfield support in cffi? (as in { int bar : 3}, not DEFBITFIELD) IIRC it does support bitfields, but i couldn't find it in the code.
defcstruct doesn't support bitfields, no. It shouldn't be too hard to implement, though. The harder bit is figuring out the packing layout, but, if we know the offsets, then we can skip that.
the OFFSET slot in FOREIGN-STRUCT-SLOT doesn't say anything about the unit it's assuming, but the way it's used in MEM-REF suggests it's in bytes (as opposed to bits), right?
Yes, bytes.
It shouldn't be too hard to add :bit-offset and :bit-width options. Let me know if you need help with that.
Cheers,