Re: Common FFI declarations

  • From: Duncan Cross <duncan.cross@xxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Tue, 8 May 2012 15:57:16 +0100

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

Other related posts: