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,