lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


>>>>> "Roberto" == Roberto Ierusalimschy <roberto@inf.puc-rio.br> writes:

 >> Code written for 5.4.2 expects lua_pop / lua_settop to close
 >> variables, but as soon as you load it with a 5.4.3 binary or .so,
 >> that stops happening and the code no longer behaves correctly (if
 >> you build lua with asserts you can get an assert failure, I haven't
 >> explored what can happen without asserts but I bet it's possible for
 >> it to crash).

 Roberto> Probably we should have put LUA_COMPAT_5_4_0 on by default.

If you want to make changes that warrant a LUA_COMPAT_* compile option,
then you should be making a new major version. As it stands, there's no
way for source code to know whether it should be trying to use the 5.4.2
or 5.4.3 protocols for close vars, and _even if it could know at compile
time_ it would break at runtime since there's no way for a module to
know whether it's linked against 5.4.2 or .3.

 Roberto> I don't see how that error could crash Lua.

What about the fact that L->tbclist is now pointing off the top of the
stack? Are you guaranteed that (even after, say, a garbage collection)
that the invariants that luaF_close relies on are still maintained?

 Roberto> Our thinking in this change is that probably very few people
 Roberto> are already using to-be-closed variables in the C API,

Hi. I'm one of those "very few people".

 Roberto> so this change would affect very few people. To wait for 5.5
 Roberto> for this change (in particular for adding lua_closeslot) would
 Roberto> make the incompatibility more troubling.

Then you need to break the API even further to make sure there aren't
silent failures; my suggestion would be for 5.4.3 to have a new #define
for lua_toclose that changes the external function name, so that code
compiled for 5.4.2 that uses lua_toclose will fail to load under 5.4.3
due to the missing function. (Code written for 5.4.3 that uses
lua_closeslot will obviously fail to load under 5.4.2 the same way.)

Then those "few" of us (neither you nor I know how many of us there
really are) can just say "this code requires 5.4.3 minimum".

(I've mentioned in the past that you should add a way for modules to
know at runtime the full version of the interpreter, not just the major
version. This already came up with 5.3.6 (whether workarounds for the
lua_pushcfunction bug are required) and 5.4.2 (whether the C stack size
needs to be set), and now we see it again.)

-- 
Andrew.