Question regarding lua_gc interface

[JCash]

Hi, and thank you for this library!

I have a question regarding the interface of lua_gc().

Overall, it looks like that the lua.h header from both Luau and Lua 5.1 are mostly the same.
However, I noticed that the enums being passed to the lua_gc() function have different values:

Luau:

LUA_GCSTOP,         // 0
LUA_GCRESTART,      // 1
LUA_GCCOLLECT,      // 2
LUA_GCCOUNT,        // 3
LUA_GCCOUNTB,       // 4
LUA_GCISRUNNING,    // 5
LUA_GCSTEP,         // 6
LUA_GCSETGOAL,      // 7
LUA_GCSETSTEPMUL,   // 8
LUA_GCSETSTEPSIZE,  // 9

Lua 5.1:

#define LUA_GCSTOP              0
#define LUA_GCRESTART           1
#define LUA_GCCOLLECT           2
#define LUA_GCCOUNT             3
#define LUA_GCCOUNTB            4
#define LUA_GCSTEP              5
#define LUA_GCSETPAUSE          6
#define LUA_GCSETSTEPMUL        7

E:g. LUA_GCSTEP has different values.

My concern is regarding other 3rd party libraries having built with Lua 5.1, and us switching out the VM to Luau.
It should work as long as the public api's are the same, and this is one such case where it feels like an issue.
What are your thoughts around this. Is this something that is in line with your design goals for Luau?

Would you consider a PR for this enum?
Are there other areas where you would see a similar issue between the headers?

Regards,
Mathias

[zeux]

There is definitely going to be an issue that's not just limited to this enum if you link both Luau and Lua or compile a third-party library against lua.h from Lua but link Luau. Depending on build system settings there may be conflicts between various functions, and the virtual machines are not interoperable apart from having a similar interface. This is similar to linking multiple versions of Lua 5.x into the same binary.

If Lua 5.1 is compiled as C and Luau is compiled as C++, then I think things will happen to work because of different mangling. In this case specifically LUA_GC* values should also not be an issue unless I'm misunderstanding the question.

[zeux]

(there's not an actual issue with us changing the LUA_GC values, they aren't ordered in a particular way - I think we may have added GCISRUNNING to align with later Lua versions but reordering these should be fine... it's just that it should be neither necessary nor sufficient for what you're trying to do I think)

[JCash]

Hi!
Thanks for the reply.

Oh, I'm not talking about linking two versions (Lua+Luau) at the the same time but rather choosing at link time (user's choice) which library to link with (either Lua or Luau)
That works if the libraries share the same api (as specified by the headers), but currently they do differ.

I've read the Luau notes a bit more carefully and it seems not all features will work the same (e.g. loadstring, io/os/debug libraries) etc. So it will likely be hard for us to add support for it as-is but it would be good to decide (document) if the Luau headers will or will not be intended to be compatible with Lua 5.1. (if that makes sense?)

[zeux]

We never intended Luau to be link-compatible with Lua 5.1 headers, just like Lua 5.x headers aren't link-compatible with each other. Luau is not a library in general - it's a programming language that has a C embedding interface that is as close to Lua 5.1 as we can reasonably make it without compromising other goals, and that as a language is a superset of Lua 5.1, but that doesn't mean you can LD_PRELOAD a new .so into an existing application that uses Lua 5.1.

[zeux]

As far as documentation, we currently don't have documentation for C interface; the lack of this documentation as well as a brief summary of differences is listed here: #251. Note that the differences listed there are source-level, for example the GC difference you highlighted is ABI-level - as noted before, ABI compatibility with Lua 5.1 was just never a goal.

[JCash]

Thanks again for the info, much appreciated!

I understand. I will have to figure out another way to support it... 🤔