RFC on changes to enum and bitfield semantics

Marco Antoniotti marcoxa at cs.nyu.edu
Wed Jan 13 21:46:45 UTC 2016


I know it is very much OT (sorry :) ), but I could not pass the chance for some self-promotion :) :)

Check this out: http://defenum.sourceforge.net

Cheers
—
MA




> On Jan 13, 2016, at 22:26 , Attila Lendvai <attila at lendvai.name> wrote:
> 
> 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,
> 
> -- 
> • attila lendvai
> • PGP: 963F 5D5F 45C7 DFCD 0A39
> --
> “The cost of sanity in this society, is a certain level of alienation.”
> 	— Terence McKenna (1946–2000)

--
Marco Antoniotti





More information about the cffi-devel mailing list