Re: FFI in interpreter mode

  • From: Evan Wies <evan@xxxxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Wed, 23 May 2012 23:51:42 -0400

On 05/23/2012 01:58 PM, James McKaskill wrote:
On Wed, May 23, 2012 at 1:41 PM, Evan Wies<evan@xxxxxxxxxxxxx>  wrote:
Thank goodness for unlimited scrollback...   in order:

Issues within ffi.cdef (which LuaJIT allowed):

  * It didn't like a static const int within a struct:
  *   unknown type static on line 215
Thanks. Filed as https://github.com/jmckaskill/luaffi/issues/29

  * It didn't like redeclarations of types:
  *   type 'struct ' previously declared as 'unsigned char[48]'
Can you give me some more context on this one. Was this just
redeclaring the same like:

typedef foo unsigned char[48];
typedef foo unsigned char[48];
It was:
typedef uint8_t foo_t[48];
typedef struct foo_t {
    // 48 structured bytes
} foo_t;


  * Similarly, something was typedef'd as an unsigned int and turned into an
enum later:
  *   type 'enum ' previously declared as 'unsigned int'
Wow. You learn something new every day. I didn't even know this was
legal C. Filed as https://github.com/jmckaskill/luaffi/issues/30

This is all generated from an XML file, with a specific Lua-for-LJ2FFI target (i.e. it has ffi.cdef([[structs]]) ). I'm not feeding it to a compiler. I haven't done exhaustive tests with the resulting ffi.cdef's, but it does load successfully with luajit.

-Evan


While hooking up a signal hander:

S.sigaction( S.SIGINT, function(sig) g_terminated = true end )
lua: unable to convert argument 8 from lua<table>  to cdata<uint64_t>
stack traceback:
    [C]: in function 'sigaction_t'
    ./io/syscall.lua:2880: in function 'sigaction'
    ....
Filed as https://github.com/jmckaskill/luaffi/issues/31. I think its
getting confused between struct sigaction vs sigaction().

The previously mentioned one conversion issues:

lua: unable to convert argument 2 from cdata<int>  to cdata<int64_t>
stack traceback:
    [C]: in function 'open'
    ./io/syscall.lua:2388: in function 'open'

(my line numbers for syscall.lua might be different than what's on github)
Odd. It shouldn't be creating cdata<int>  in the first place.

Thanks for the reports.

-- James



Other related posts: