On Tue, May 8, 2012 at 3:09 PM, Mike Pall <mike-1205@xxxxxxxxxx> wrote: > The first one that comes to mind are the basic types for the WIN32 > API. Not sure whether to split these up. There are plenty of types > that only make sense if you declare the related functions, too. > Luckily, the WIN32 types are cast in stone and they don't change > that much for Windows/x64. This probably needs to be designed > along a somewhat complete WIN32 binding (which should go into an > extra module, not shipped with the core). This reminds me of something: in the WIN32 API, and a few other APIs, the boolean type ("BOOL" in WIN32's case) is unfortunately not the same bit-width as the C99/C++ 'bool' type, so you have to use an integer type instead. This means you lose the ability to have real Lua booleans directly returned from cdata functions/retrieved from cdata struct fields/passed as callback parameters. It's not a huge problem, but it seems a bit asymmetrical since you can pass in 'true' and 'false' to integer parameters/field structs without noticing the silent conversion that takes place. Maybe this falls under "no hand holding" policy, and I know you're probably loathe to add your own "extensions" to cdef, but I think in this case it might be justified. Something like this maybe: ffi.cdef [[ typedef __ffi_boolean__ int BOOL; ]] -- test assert(ffi.sizeof 'BOOL' == ffi.sizeof 'int') print(ffi.new('BOOL[1]', 1)[0]) --> true -Duncan