[sshumaker]

Lua has great C integration, but LuaJIT's is even better. You can natively interface with C code without a recompile, just by defining the C function prototype in Lua, and using it like you would any normal lua function. Better still, LuaJIT can frequently inline the calls to C code, so there's no cross-language marshaling penalty.

Check out http://luajit.org/ext_ffi_tutorial.html

[haberman]

FFI is extremely cool and impressive, no doubt, but a major downside of it is that you give up memory safety. Once you import it your Lua program can SEGV the interpreter and read/write arbitrary memory in your process. Freedom from memory errors is a major motivation for using high-level languages, so this should not be given up lightly. Also, from a security standpoint it means your Lua is less sandboxed.

[sshumaker]

Yes, but you use it to interface with native code. Normally, you'd write Lua_Cfunctions to achieve the same behavior - and those can crash your app just as easily, since they're native code. Perhaps more so, since it's easy to screw up the stack manipulation.

[haberman]

Yes, but the point is that once you've loaded FFI you have to trust 100% of the Lua. With a Lua C extension you have to trust the extension, but not the Lua that loads it.

[justincormack]

You can still sandbox it and not provide direct access to ffi to user code, only some tested ffi calls. Just like native in that way.

[haberman]

If FFI is loadable, how are you going to prevent your untrusted script from loading it and going to town? How are you going to avoid providing "direct access?" My whole point is that I don't think you can. It's all or nothing. If ffi is available to some Lua code, it is available to all of it.

I even asked Mike Paul (LuaJIT author this question, and he said "That's not a viable approach for sandboxing.") http://lua-users.org/lists/lua-l/2011-02/msg01582.html

[batista]

OK, native code can crash. Not much of a problem. He have been running servers written in C/C++ since the ancient times for more critical tasks than your average Lua program. From Apache to Nginx and from Qmail to MySQL to MongoDB. So what if a Lua program has the "potential" to crash if you interface with C?

You do the interfacing because there is a need to do it, anyway. It's not like you go FFI for fun.

[eridius]

haberman's argument is making an assumption that perhaps you aren't. Namely, one of the benefits of Lua is that, barring behavior introduced by C extensions (and bugs in the Lua interpreter), it can't really harm your program. It can't crash or do anything else. It can suck up resources, but that's about it. As such, with whatever sandboxing you feel is appropriate, you can run arbitrary Lua code without worrying (e.g. World of Warcraft can run third-party addons). But with LuaJIT's FFI interface, it appears (note: I have never used LuaJIT or its FFI interface) that you can no longer trust arbitrary Lua because it can reach into your program and call whatever function it feels like, including the ability to crash you at random, or do other things that it's not supposed to be able to do. You can no longer just trust Lua code to not impact the rest of your program.