diff mbox series

lua: Use LUA_VERSION_NUM for compatibility checks

Message ID 20261027184420.75223-1-valter.jansons@gmail.com
State Accepted
Headers
Series lua: Use LUA_VERSION_NUM for compatibility checks |

Commit Message

Valters Jansons 27 Oct 2026, 6:44 p.m. UTC 
luaL_setmetatable, luaL_setfuncs, and luaL_newlib were added to
lauxlib.h in Lua 5.2. This project added compatibility functions to
allow building on older Lua versions. It checks whether the version
number is below 502 as to determine if the functions will be missing.

However, LUA_VERSION_RELEASE_NUM was erroneously used for this check.
This value was only added in Lua 5.4, and it follows a different
numbering scheme - including the release/patch number, such as 50409
for Lua 5.4.9. The proper constant to use is LUA_VERSION_NUM, which
follows the expected scheme, such as 504 for Lua 5.4.9. This same
constant is already used later in the same compat.h file.

This commit ensures the older Lua versions build as expected. Otherwise
"Lua 5.1 or older" compatibility logic is triggered even for Lua 5.2 and
5.3 where the preprocessor will automatically replace the undefined
version identifier with zero. Even more worryingly, if someone attempts
to enforce stricter definition safety with `-Werror=undef` then the
libloc 0.9.20 build will fail outright on versions older than Lua 5.4.

Signed-off-by: Valters Jansons <valter.jansons@gmail.com>
---
Essentially, if the packages only build for Lua 5.1 and 5.4 and nobody
sets `-Werror=undef`, then there are no issues. However, if either of
those assumptions breaks, then the builder will not be happy.

 src/lua/compat.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comments

Michael Tremer 27 Oct 2026, 7:43 p.m. UTC | #1 
Hello Valters,

Thank you for the patch, I will merge it shortly.

Initially I was developing the Lua bindings against Lua 5.4 which was the latest version at the time. I am also using this in PowerDNS to serve the database over DNS which using LuaJIT which in only compatible to Lua 5.1. God knows why. That is why I was building them that way.

Normally the bistro build systems only build against one version of Lua, but Debian can build against multiple, because there are some other things stuck on 5.2, 5.3 and so on. So I am happy to keep the code compatible and I am also happy to build against all of the versions. There will be someone out there using it.

——

Regarding your and other people’s submissions, I am very happy to have them and merge them. This is great and I want this project to be a community effort. I want to avoid however that your patches are aging in the branch for a long time until there is a release tagged. So would it be helpful to communicate this beforehand? Is there anything you guys are working on, or integrating this library in? I don’t know much about your use-cases and applications, so I did not really think of reaching out before tagging a release. Please let me know if this would help, so that we can coordinate it better and get any code shipped quickly.

We now have an extensive test suite and so making any changes feels a lot less risky and requires less testing out in the field.

All the best,
-Michael

> On 27 Oct 2026, at 18:44, Valters Jansons <valter.jansons@gmail.com> wrote:
> 
> luaL_setmetatable, luaL_setfuncs, and luaL_newlib were added to
> lauxlib.h in Lua 5.2. This project added compatibility functions to
> allow building on older Lua versions. It checks whether the version
> number is below 502 as to determine if the functions will be missing.
> 
> However, LUA_VERSION_RELEASE_NUM was erroneously used for this check.
> This value was only added in Lua 5.4, and it follows a different
> numbering scheme - including the release/patch number, such as 50409
> for Lua 5.4.9. The proper constant to use is LUA_VERSION_NUM, which
> follows the expected scheme, such as 504 for Lua 5.4.9. This same
> constant is already used later in the same compat.h file.
> 
> This commit ensures the older Lua versions build as expected. Otherwise
> "Lua 5.1 or older" compatibility logic is triggered even for Lua 5.2 and
> 5.3 where the preprocessor will automatically replace the undefined
> version identifier with zero. Even more worryingly, if someone attempts
> to enforce stricter definition safety with `-Werror=undef` then the
> libloc 0.9.20 build will fail outright on versions older than Lua 5.4.
> 
> Signed-off-by: Valters Jansons <valter.jansons@gmail.com>
> ---
> Essentially, if the packages only build for Lua 5.1 and 5.4 and nobody
> sets `-Werror=undef`, then there are no issues. However, if either of
> those assumptions breaks, then the builder will not be happy.
> 
> src/lua/compat.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/src/lua/compat.h b/src/lua/compat.h
> index c1a13a2..a5106c6 100644
> --- a/src/lua/compat.h
> +++ b/src/lua/compat.h
> @@ -20,7 +20,7 @@
> #include <lua.h>
> #include <lauxlib.h>
> 
> -#if LUA_VERSION_RELEASE_NUM < 502
> +#if LUA_VERSION_NUM < 502
> 
> static inline void luaL_setmetatable(lua_State* L, const char* name) {
> luaL_checkstack(L, 1, "not enough stack slots");
> -- 
> 2.56.0
> 
>
Valters Jansons 27 Oct 2026, 8:30 p.m. UTC | #2 
> Thank you for the patch, I will merge it shortly.

Thank you!

> I don’t know much about your use-cases and applications, so I did not really think of reaching out before tagging a release.

There has been a change in my day-to-day tasks, so I am not actively
involved in running libloc in production now. My latest personal
use-case was a simple one - for geo-limiting in nftables. However, I
continue contributing to ensure updates get shipped to the main Debian
archive. I initially thought everything builds fine and didn't notice
all the concerns that got flagged later in extended testing suites and
more exotic scenarios (for example, this latest issue with older Lua
versions cropped up when building with `-Werror=undef` -- otherwise
the default preprocessor logic hides it).

In any case, I think it's reasonable for you to just tag a release if
it looks good for you. If something pops up, I will circle back
around. I am not sure if a "release candidate" workflow is really
warranted, and I think it would just make the whole process more
cumbersome for everyone involved.

So, although this cycle of release feels more messy (notably due to
there being various packaging changes), I also think that future
releases will be more smooth as most concerns get ironed out.

Let me know as well, if you see some potential improvements.

Best regards
Valters
diff mbox series

Patch

diff --git a/src/lua/compat.h b/src/lua/compat.h
index c1a13a2..a5106c6 100644
--- a/src/lua/compat.h
+++ b/src/lua/compat.h
@@ -20,7 +20,7 @@ 
 #include <lua.h>
 #include <lauxlib.h>
 
-#if LUA_VERSION_RELEASE_NUM < 502
+#if LUA_VERSION_NUM < 502
 
 static inline void luaL_setmetatable(lua_State* L, const char* name) {
 	luaL_checkstack(L, 1, "not enough stack slots");