[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: [ANN] Lua 5.4.3 (rc1) now available
- From: Andrew Gierth <andrew@...>
- Date: Fri, 05 Mar 2021 15:54:18 +0000
>>>>> "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.