RFC on plans to implement a c2ffi->cffi generator

[Luís Oliveira]

Attila Lendvai <attila at 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 at 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,

-- 
Luís Oliveira
http://kerno.org/~luis