RFC on plans to implement a c2ffi->cffi generator

[Attila Lendvai]

> 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.


in cl-autowrap, and in my current cffi-c2ffi code, there are ways to
filter out files and/or definitions to focus only on the interesting
parts of the bindings. this keeps its size within reasonable limits,
as it'd also be pointless for each cl binding project to contain the
whole linux/c stuff -- plus a little interesting extra.

omitting the slot seems to have been too obvious an idea to come to
me... thanks for drawing my attention! :)

i'll just change the generator to emit the slots that refer to a not
yet defined type as a comment (to retain human readability).

the struct size is already part of the generated output. i'll try to
record some v0.1 state soon so that interested parties can also look
at what's working already.


> It's only possible to reference a struct with "some_struct" when there's
> a "typedef struct some_struct some_struct".


that helps, thanks!

so, essentially there are a few namespaces in C:

 - default (typedef, functions, variables)
 - struct
 - union (or it's the same namespace as struct?)

does someone know about a documentation on this? i couldn't find
anything on this topic specifically...


> 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?


that shouldn't be needed because to the best of my knowledge the order
in the json file is the same as in the preprocessed C file.


>> 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.


ehh, time flies! :) and apparently this issue has not yet been
resolved by any opensource fairies in those 8 years.


> 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.


yep, we know bit-offsets (and bit-sizes) from the c2ffi output. it
would be nice if there was at least an API (that initially throws an
error in the runtime accessors that it's not yet implemented?).

but i guess it's not urgent. cffi-c2ffi can always filter those out,
and support added later on.


>> 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.


i started to follow the convention to store everything in its natural
unit (length in meters, time in seconds, etc). i'm aware of the pain
it would take to migrate from bytes to bits under the same name, but
it still tickles my idealism, especially if we bring in C bitfield
support that deals with bits.


> It shouldn't be too hard to add :bit-offset and :bit-width options. Let
> me know if you need help with that.


i will not jump on it for now, but as i wrote above it's also not
urgent to be implemented in the first wave of features.

thanks,

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“What will a free society [without Government] do about criminals? Not
give them access to a god damned army, for starters.”
	— Stefan Molyneux (1966–)