Re: LuaJIT FFI vs Lua binding vs Lua interface

[William Ahern <william@...>]

On Sat, Jun 23, 2012 at 07:43:11AM +0900, Miles Bader wrote:
> Francesco Abbate <francesco.bbt@gmail.com> writes:
> >> Nonetheless, I think more core support would be necessary to get
> >> around the portability issues (if that's even possible, though my
> >> guess it is for at least some reasonable subset of the functionality).
> >
> > I guess this discussion will not bring us anywhere if neither Roberto
> > or Luiz step forward to say a word on this idea :-)
> 
> It also occurred to me that while there are probably many parts of FFI
> which could be made more portable, there are some important operations
> which are simply impossible to do portably at runtime in standard C.
> 
> One famous example is calling a function with an arbitrary signature.
> I.e. if you have a function pointer, and a list of the argument types
> (only known at runtime), and some way of getting the values for the
> arguments, there's no really portable way to call the function pointer
> with those arguments.
> 
> Unfortunately that exact operation is also one of the main uses of FFI
> ... :(
> 

You can do it for a limited number of arguments and without compound type by
defining a huge map of function pointers. I'm not sure what the equation is,
but obviously the permutations grow quickly.

Intuitively, though, I think it should be practical for 3 or 4 parameters.
Given the integer promotions rules (you don't need to worry about char or
short), and assuming that a void pointer parameter signature can stand in
for any object pointer (likely on most platforms), then it's not too far
fetched. Just really frustrating when the caller wants to pass that one
extra parameter which can't be supported. The argument limit would seem
completely arbitrary from the user's perspective.