Re: LuaJIT and symbol versioning

  • From: Peter Cawley <corsix@xxxxxxxxxx>
  • To: luajit@xxxxxxxxxxxxx
  • Date: Sun, 16 Aug 2015 15:07:19 +0100

On Sun, Aug 16, 2015 at 10:16 AM, Nagaev Boris <bnagaev@xxxxxxxxx> wrote:

LuaJIT is binary backward compatible with Lua 5.1. Lua modules
compiled with Lua 5.1 can be loaded with LuaJIT. This feature would
not work if LuaJIT had another symbol label.

If you just consider symbol names and their signatures, then sure. If
you also consider the semantics of the symbols, then LuaJIT isn't a
total 100% drop-in replacement for PUC-Rio Lua 5.1. For example:

* On 64-bit architectures without LJ_GC64, you can't really pass a
custom allocator to lua_newstate, and you need to ensure that a
sufficient portion of the low 2GB of address space is available.
* lua_load doesn't accept PUC-Rio Lua 5.1 bytecode, and instead
accepts LuaJIT2 bytecode.
* lua_dump gives out LuaJIT2 bytecode rather than PUC-Rio Lua 5.1 bytecode.
* lua_pushnumber can be used to push all sorts of NaNs on to the stack
for PUC-Rio Lua 5.1, but not so much for LuaJIT2.
* `lua_tocfunction(L, n) != NULL` and `lua_iscfunction(L, n) != 0` are
no longer synonymous (technically this isn't true in PUC-Rio Lua 5.1
either, as `lua_pushcclosure(L, NULL, 0)` is "permitted", but in
practice nobody would ever do that, whereas in LuaJIT2, various chunks
of the standard library have `lua_iscfunction(L, n) != 0` despite
`lua_tocfunction(L, n) == NULL`).
* The debug API isn't quite the same (per-universe hooks rather than
per-coroutine hooks, return hooks for non-Lua functions, etc.)
* Implementation bugs which exist in one of Lua 5.1 / LuaJIT2, but not
the other (e.g. debug.setupvalue on otherwise-constant upvalues)

Consequently, if you want to maximise your chance of not breaking
things, it seems sensible to give PUC-Rio Lua 5.1 to things which ask
for PUC-Rio Lua 5.1, give LuaJIT2 to things which ask for LuaJIT2, and
not give one to something which asks for other.

Other related posts: