on my quest to implement an automatic generator for CFFI bindings (using c2ffi), i've recorded some patches that change the semantics of enums and bitfields.
automatically generated bindings (should) live in an empty lisp package, and to avoid surprises it's also desirable to bring the CFFI behavior (regarding e.g. C namespaces) as close to C as possible.
the code is available in this PR: https://github.com/cffi/cffi/pull/84
the following are controversial and i'd welcome some input on them from CFFI gurus, especially regarding what should/could get into master eventually:
- enums don't demand member names to be CL:KEYWORDP anymore
- DEFCENUM and DEFBITFIELD now expand a toplevel DEFCONSTANT for each member. the rationale is to bring it closer to the C enum semantics where they are in the main namespace.
- BITFIELD now inherit from ENUM, and adds extra semantics for values that are the power of two. but should 0 be treated as a bitfield bitmask? IOW, should (FOREIGN-BITFIELD-SYMBOLS 'FOO 0) return NIL or '(ZERO-MEMBER-NAME)? the code currently does not treat 0 as a bitmask (which is an incompatible change).
- the accessor names are rather inconsistent: FOREIGN-ENUM-VALUE FOREIGN-BITFIELD-VALUE FOREIGN-ENUM-KEYWORD FOREIGN-BITFIELD-SYMBOLS FOREIGN-ENUM-KEYWORD-LIST FOREIGN-BITFIELD-SYMBOL-LIST i'd like to rename the last four of them to (not done yet): FOREIGN-ENUM-KEY FOREIGN-BITFIELD-KEYS FOREIGN-ENUM-KEY-LIST FOREIGN-BITFIELD-KEY-LIST and leave some aliases and deprecation warnings behind. but are the names ok? or any better ideas?
- another minor issue is that 'bitfield' is a confusing name, because the C standard calls the 'int:3' kind of types as bitfields. i suggest to rename them to 'bitmask' in CFFI. maybe incompatibly? or only in a new major version?
it'd be nice if this could be merged before the next quicklisp release, because there are some projects that depend on them that i'd like to get into ql the sooner the better.
thanks, and happy hacking,