Cdata/FFI feature proposition

  • From: QuentinC <webmaster@xxxxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Fri, 10 Aug 2012 06:22:46 +0200

I have a feature proposition.

Change the string returned by a ctype object's __tostring so that it can always be used as a valid argument for a later ffi.cast.

print(ffi.typeof('struct something*'))) -- "ctype<struct someting *>" already OK

print(ffi.typeof('char[?],10))) -- "ctype<char[?]>" not OK, could be read as "cdata<char*>" or allow something like "char[?]" or "char[]" in ffi.cast

ffi.cdef[[ int afunc (int foo, int barr); ]]
print(ffi.typeof(ffi.C.afunc)) -- "ctype<int()>" not OK, should read "ctype<int(*)(int,int)>".

The later may also be useful to dynamically get information about arguments needed to call the function (by parsing the string). Since you do type check before actually calling the native function, I assume you basicly have that information.

Alternative idea :
Add a ffi.type(cdata) function that return a valid string for a later ffi.cast (and getting rid of "ctype<" and ">"), if base idea is impossible. Since ffi.typeof is already doing most of the job, it's perhaps useless to add another function that may introduce confusion. I read that you weren't much for that option, and I completely agree considering that point.

Why this feature ?
1. Inter-state communication
Inter-state communication, assuming of course that involved ctypes are properly defined where they are used (That's the responsibility of the user, not luajit). Having a string valid for ffi.cast allow to pass a lightuserdata to another VM and then do an automated ffi.cast at arrival, or program a more sophisticated routine that can copy data based on the type, etc.

2. Dynamic typing, clone, etc.
Having a valid ffi.cast string allow a cdata to be cloned without knowing its exact type. I have no example, but i'm sure that it can be useful sometimes.

Thank you for reading.

Other related posts: