[ANN] Lua 5.5.0 (beta) now available

[Luiz Henrique de Figueiredo]

Lua 5.5.0 (beta) is now available for testing at
https://www.lua.org/work/lua-5.5.0-beta.tar.gz

The SHA256 checksum is
30897f95fc72565cb6c1792f721ad44e1a42e7ac587f62f7587807b3cbff1645  -

The Git commit ID is
cfce6f4b20afe85ede2182b3df3ab2bfcdb0e692

This is a beta version. Some details may change in the final version.

The main changes in Lua 5.5.0 are listed at
https://www.lua.org/work/doc/#changes

An updated reference manual is included and also available at
https://www.lua.org/work/doc

A test suite is available at
https://www.lua.org/work/lua-5.5.0-tests.tar.gz

All feedback welcome. Thanks.
--lhf

[Luiz Henrique de Figueiredo]

Besides the changes listed in
https://www.lua.org/work/doc/#changes
also noteworthy are:
- the removal of LUA_COMPAT_5_3 from all builds
- the removal of LUA_USE_READLINE in the linux tagert
- the removal of the linux-readline and linux-noreadline targets
lua.c now detects the availability of readline.

[eugeny gladkih]

re,

may I suggest some ‘global’ improvement? it seems to be good to have a compilation flag or even a parameter for lua_newstate to disable implicit ‘global *’ in a chunk start. for us who are paranoids :)

> --
> You received this message because you are subscribed to the Google Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
> To view this discussion visit https://groups.google.com/d/msgid/lua-l/12df2e1b-3ab3-4903-866a-7745024b862cn%40googlegroups.com.


--
Yours sincerely, Eugeny.

[Scott Morgan]

On 30/06/2025 14:22, Luiz Henrique de Figueiredo wrote:
> Besides the changes listed in
> https://www.lua.org/work/doc/#changes
> also noteworthy are:

...

> - the removal of LUA_USE_READLINE in the linux tagert
> - the removal of the linux-readline and linux-noreadline targets
> lua.c now detects the availability of readline.

Was wondering about that, thanks.

Scott

[Xavier Wang]

All feedback welcome. Thanks.
--lhf

It seems that ‘table.create’ not appears in the “Index” section of the manual. 

[Luiz Henrique de Figueiredo]

> It seems that ‘table.create’ not appears in the “Index” section of the manual.

Thanks for spotting this!
To fix it, add this line after line 314 in doc/contents.html:
<A HREF="manual.html#pdf-table.create">table.create</A><BR>

[Eleanor Bartle]

I really think there should be a note in the manual about the interplay between global and _ENV. In particular, that the translation to _ENV.var happens not at the declaration, but at the usage site, meaning the same declaration could potentially declare different variables per use.

[ubq323]

it might be nice if there was a way to say 'no globals at all'

the manual suggests 'global none', which means that 'none' is the only global variable... which feels a little hacky to me

(i don't know what the syntax for such a thing should be)

[blog...@gmail.com]

>more levels for constructors

Im dont understend, What does this mean? :)

вторник, 1 июля 2025 г. в 10:40:25 UTC+3, Eleanor Bartle:

[Roberto Ierusalimschy]

> >more levels for constructors
>
> Im dont understend, What does this mean? :)

It means you can nest more constructors with many elements inside each
other. Conside the following code:

return {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,}}}}}}}

It doesn't compile in 5.[1234] ("function or expression too complex" or
"function or expression needs too many registers"), but it does in 5.5.

-- Roberto

[Benoit Germain]

I have 3 warnings when compiling for x86 with Microsoft Visual Studio Professional 2022 Version 17.14.7
U:\Lua\Lua55\src\lstrlib.c(1814,47): warning C4244: 'function': conversion from 'lua_Unsigned' to 'size_t', possible loss of data
U:\Lua\Lua55\src\lstrlib.c(1815,16): warning C4244: '+=': conversion from 'lua_Unsigned' to 'size_t', possible loss of data
U:\Lua\Lua55\src\lundump.c(112,10): warning C4244: 'return': conversion from 'lua_Unsigned' to 'size_t', possible loss of data
These do not exist when building for x64.

--
You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/20250701145026.GA143599%40arraial.inf.puc-rio.br.

--

Benoit.

[blog...@gmail.com]

>It means you can nest more constructors with many elements inside each

other. Conside the following code:

Oh! Thanks I'll go update the news about the new version of Lua on my local forum and add this nuance.

вторник, 1 июля 2025 г. в 17:55:54 UTC+3, Benoit Germain:

[Roberto Ierusalimschy]

> I have 3 warnings when compiling for x86 with Microsoft Visual Studio
> Professional 2022 Version 17.14.7
> U:\Lua\Lua55\src\lstrlib.c(1814,47): warning C4244: 'function': conversion
> from 'lua_Unsigned' to 'size_t', possible loss of data
> U:\Lua\Lua55\src\lstrlib.c(1815,16): warning C4244: '+=': conversion from
> 'lua_Unsigned' to 'size_t', possible loss of data
> U:\Lua\Lua55\src\lundump.c(112,10): warning C4244: 'return': conversion
> from 'lua_Unsigned' to 'size_t', possible loss of data
> These do not exist when building for x64.

Many thanks for the feedback. (With 64 bits, size_t and lua_Unsinged
are both uint64; with 32 bits, size_t becomes uint32.)

-- Roberto

[blog...@gmail.com]

I'm not sure, but this code should definitely work? I thought there would be an error if I declared local global

```

local global = 5
global <const> *  -- all globals vars is const
global  = 5           -- but global keyvar not :)
print(global)
global *
print(global)
global x
x = 10
print(x,global)
y = 20

```

It looks like the global keyword can now act as both a keyword and a variable at the same time.

If add in last

```

local global = 5
global <const> *
global  = 5   
print(global)
global *
print(global)
global x
x = 10
print(x,global) -- global as var name == 5
global <const> y -- global as keyword
y = 20 -- ok, triggered "attempt to assign to const variable 'y'"

```

Or maybe I just haven't understood something yet.

вторник, 1 июля 2025 г. в 18:53:11 UTC+3, Roberto Ierusalimschy:

[Roberto Ierusalimschy]

> I'm not sure, but this code should definitely work? I thought there would
> be an error if I declared local global
>
> ```
> local global = 5

> [...]

> It looks like the global keyword can now act as both a keyword and a
> variable at the same time.

This is for compatibility only. Old code may use 'global' as a name.
(For instance, there is a package in LuaRocks that defines a function
'global' that declares globals.) You can undefine LUA_COMPAT_GLOBAL
in luaconf.h to make "global" a real reserved word.

-- Roberto

[blog...@gmail.com]

>This is for compatibility only ...You can undefine LUA_COMPAT_GLOBAL

Big Thanks a lot for the explanation.

вторник, 1 июля 2025 г. в 20:13:37 UTC+3, Roberto Ierusalimschy:

[Andrey Dobrovolsky]

> > >more levels for constructors
> >
> > Im dont understend, What does this mean? :)
>
> It means you can nest more constructors with many elements inside each
> other. Conside the following code:
>
> return {1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,{1,1,1,1,1,1,1,1,1,1,1,
> 1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,}}}}}}}
>
> It doesn't compile in 5.[1234] ("function or expression too complex" or
> "function or expression needs too many registers"), but it does in 5.5.
>
> -- Roberto

Thanks for paying attention to this topic

-- Andrew

[Kevin Li]

On Monday, June 30, 2025 at 8:43:16 AM UTC-4 Luiz Henrique de Figueiredo wrote:

All feedback welcome. Thanks.
--lhf

(Sorry in advance for the potentially duplicate message...still trying to figure out mailing lists.)

Much thanks to Luiz and the rest of the Lua team. 

May I ask about this line in the incompatibility section? 

* A chain of __call metamethods can have at most 15 objects.

I maintain a compiler (unfortunately cannot share source) that targets/transpiles to Lua. It is not inconceivable (though highly implausible) that it can generate code which looks like: "tab()()()()....()", more than 15 levels deep, where tab() and each of the intermediate __call's returns a table which has a __call. 

Would this be unsupported in Lua 5.5? 

Thanks a lot! 

Cheers, Kevin

[Sainan]

I think it's meant that if your metatable has a __call which itself is not callable but has __call, e.g.:

local t1 = setmetatable({}, {
__call = function() print("hi") end
})
local t0 = setmetatable({}, {
__call = t1
})
t0()

In this case, this has 1 level of indirection. I take it to mean that they're limiting that to 15 levels of indirection.

-- Sainan

[Roberto Ierusalimschy]

> * A chain of __call metamethods can have at most 15 objects.
>
> I maintain a compiler (unfortunately cannot share source) that
> targets/transpiles to Lua. It is not inconceivable (though highly
> implausible) that it can generate code which looks like:
> "tab()()()()....()", more than 15 levels deep, where tab() and each of the
> intermediate __call's returns a table which has a __call.
>
> Would this be unsupported in Lua 5.5?

I don't think so. What you described is a chain of calls, not a chain
of __call metamethods.

A "chain" of __call metamethods is a __call metamethod that points to a
non-function object A1, which has a __call metamethod that points to a
non-function object A2, and so on.

local o = setmetatable({}, {__call = function () print(10) end})
for i = 1, 14 do --<< change to 15 and you get an error
-- create a new 'o' with previous 'o' as its _call metamethod
o = setmetatable({}, {__call = o})
end
o() --> 10

-- Roberto

[Kevin Li]

> I think it's meant that if your metatable has a __call which itself is not callable but has __call, e.g.:
>

> local t1 = setmetatable({}, {

> __call = function() print("hi") end
> })

> local t0 = setmetatable({}, {

> __call = t1
> })
> t0()

> In this case, this has 1 level of indirection. I take it to mean that they're limiting that to 15 levels of indirection.

> -- Sainan

On Tuesday, July 1, 2025 at 5:13:03 PM UTC-4 Roberto Ierusalimschy wrote:

I don't think so. What you described is a chain of calls, not a chain
of __call metamethods.

-- Roberto

Thanks a lot Sainan and Roberto for the very clear explanations.

[Marcus Lund]

On Monday, 30 June 2025 at 13:43:16 UTC+1 Luiz Henrique de Figueiredo wrote:

All feedback welcome. Thanks.
--lhf

Is the string literal "variable declarationss" correct at line 200 of lparser.c?

Should it be "variable declarations" instead? Also see similar at line 33 in the C comment.

[Benoit Germain]

Found a typo in the manual:

" Notice that, in a declaration like local x = x, the new x being declared is not in scope yet, and so the x in the left-hand side refers to the outside variable."
This should be "right-hand".

--

You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/12df2e1b-3ab3-4903-866a-7745024b862cn%40googlegroups.com.

--

Benoit.

[Benoit Germain]

In the C API reference, is there any reason for lua_numbertocstring and lua_pushexternalstring prototypes to be parenthesised?

Still about those external strings, I don't see a way to tell if a particular string value on the stack is external or not using the C API. Lanes transfers values from one state to another (both are independent states), and I would like to be able to preserve the external "flavor" of the string in that case.

Reading about luaL_makeseed triggered a side thought: I know that the VM state contains a random seed to harden it against some attacks. But when debugging some issues, it would be useful to know (or fix in advance) the value used by a given state, and a means to use the same value in a subsequent run, so that table hashing can follow the same pattern. Is it still time to consider this as an addition to Lua 5.5?

Le lun. 30 juin 2025 à 14:43, Luiz Henrique de Figueiredo <l...@tecgraf.puc-rio.br> a écrit :

--

You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/12df2e1b-3ab3-4903-866a-7745024b862cn%40googlegroups.com.

--

Benoit.

[Andrew Starks]

Building the 5.5 beta on macOS (Clang 17, arm64), I got this warning:

lua.c:492:15: warning: cast from 'int (*)(const char *)' to 'l_addhistT' (aka 'void (*)(const char *)') converts to incompatible function type [-Wcast-function-type-mismatch]

Best, 

-- Andrew Starks

To view this discussion visit https://groups.google.com/d/msgid/lua-l/CAAnJQcaoXiaQXe2jN0XsBhe5vd0%2BW%3DGaPuYwHRDFHFZA%3DByHzQ%40mail.gmail.com.

[重归混沌]

I'm working with the new lua_pushexternalstring function introduced in
Lua 5.5.0-beta, aiming to reduce unnecessary memory allocations in my
application.

However, I've encountered a coredump, and I'm hoping you can help me
understand if I'm misusing the function.

Here's a summary of the situation:

I'm using lua_pushexternalstring to push strings onto the stack.

When my program exits, it frequently core dumps. I've minimized the
code to reproduce the issue, which I've attached.

My GCC version is gcc (Debian 10.2.1-6) 10.2.1 20210110.

Running Valgrind on the minimized example gives the following output:

```
$ valgrind ./lua-5.5.0-beta/src/lua testrpc.lua
==67034== Memcheck, a memory error detector
==67034== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al.
==67034== Using Valgrind-3.19.0 and LibVEX; rerun with -h for copyright info
==67034== Command: ./lua-5.5.0-beta/src/lua testrpc.lua
==67034==
==67034== Jump to the invalid address stated on the next line
==67034== at 0x4852195: ???
==67034== by 0x1184EE: freeobj (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== by 0x11A575: luaC_freeallobjects (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== by 0x1200CA: close_state (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== by 0x10F664: main (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== Address 0x4852195 is not stack'd, malloc'd or (recently) free'd
==67034==
==67034==
==67034== Process terminating with default action of signal 11 (SIGSEGV)
==67034== Access not within mapped region at address 0x4852195
==67034== at 0x4852195: ???
==67034== by 0x1184EE: freeobj (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== by 0x11A575: luaC_freeallobjects (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== by 0x1200CA: close_state (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== by 0x10F664: main (in
/home/zhoupy/silly/MWE/lua-5.5.0-beta/src/lua)
==67034== If you believe this happened as a result of a stack
==67034== overflow in your program's main thread (unlikely but
==67034== possible), you can try to increase the size of the
==67034== main thread stack using the --main-stacksize= flag.
==67034== The main thread stack size used in this run was 8388608.
==67034==
==67034== HEAP SUMMARY:
==67034== in use at exit: 22,677 bytes in 284 blocks
==67034== total heap usage: 341 allocs, 57 frees, 37,165 bytes allocated
==67034==
==67034== LEAK SUMMARY:
==67034== definitely lost: 0 bytes in 0 blocks
==67034== indirectly lost: 0 bytes in 0 blocks
==67034== possibly lost: 8,831 bytes in 18 blocks
==67034== still reachable: 13,846 bytes in 266 blocks
==67034== suppressed: 0 bytes in 0 blocks
==67034== Rerun with --leak-check=full to see details of leaked memory
==67034==
==67034== For lists of detected and suppressed errors, rerun with: -s
==67034== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
[1] 67034 segmentation fault (core dumped) valgrind
./lua-5.5.0-beta/src/lua testrpc.lua
```

What's particularly puzzling is that the coredump does not occur if I
explicitly call collectgarbage("collect") in my Lua code before the
program exits.

This behavior makes me suspect that I might be misunderstanding or
misusing lua_pushexternalstring, especially concerning its interaction
with Lua's garbage collection.

Could anyone provide some insight into this issue?

Thank you for your time and assistance.

[Sergey Zakharchenko]

Hello list,

Luiz Henrique de Figueiredo <l...@tecgraf.puc-rio.br>:

Lua 5.5.0 (beta) is now available for testing at
https://www.lua.org/work/lua-5.5.0-beta.tar.gz

 

The introduction of external strings caught my eye; however, I also noticed that (as opposed to userdata) such strings cannot be to-be-closed; some might find using to-be-closed external strings (with obvious logic of calling falloc on close) advantageous but, as I understand, this could be difficult as small strings could be internalized and become regular strings (which are non-closable). Is there any interest in moving in this direction?

Best regards,

-- 

DoubleF

[Sainan]

> The introduction of external strings caught my eye; however, I also noticed that (as opposed to userdata) such strings cannot be to-be-closed; some might find using to-be-closed external strings (with obvious logic of calling falloc on close) advantageous but, as I understand, this could be difficult as small strings could be internalized and become regular strings (which are non-closable). Is there any interest in moving in this direction?

Strings do not have per-instance metatables like tables and userdata do, so you can't attach a __close or __gc.

This is a bit disappointing, but I definitely see that the overhead of per-instance metatables and the added uncertainty about the lifetime might not be worth it.

I think the intended usage is for static strings that comfortably outlive the lifetime of the Lua state.

-- Sainan

[Sergey Zakharchenko]

Hello Sainan,

'Sainan' via lua-l <lu...@googlegroups.com>:

> to-be-closed external strings (with obvious logic of calling falloc on close)

Strings do not have per-instance metatables like tables and userdata do, so you can't attach a __close or __gc.

Like I proposed in the quote above, the action to take on close would be to call falloc to free the string (special case in callclosemethod?). falloc is already there in the instance in this case.

I think the intended usage is for static strings that comfortably outlive the lifetime of the Lua state.

Covering this use case wouldn't need falloc at all.

Best regards,

-- 

DoubleF

[Sergey Zakharchenko]

Sergey Zakharchenko <doublef...@gmail.com>:

The introduction of external strings caught my eye; however, I also noticed that (as opposed to userdata) such strings cannot be to-be-closed; some might find using to-be-closed external strings (with obvious logic of calling falloc on close) advantageous but, as I understand, this could be difficult as small strings could be internalized and become regular strings (which are non-closable).

Seems like additional conceptual problems like what happens to extra references to such strings when the variable is closed (especially if they're used as table keys) make this complicated (though probably still solvable), so choosing not to bother with this is understandable; I just wanted to point this out as a possible design direction.

Best regards,

-- 

DoubleF

[Matthew Wild]

We would likely make use of this in Prosody. It has always been a bit
awkward passing network buffers to Lua. Basically we do (simplified):

while true
local rawdata = conn:read()
local structured = parse(rawdata)
process(structured)
end

Lua 5.2 improved this significantly when rawdata (as a long string)
was no longer unnecessarily copied, hashed and interned. But it still
involves a memcpy() for data we only need very briefly.

External strings will allow us to avoid the memcpy() now, which will
be another win. However, with <close> it means we could potentially
reuse the same buffer for the next iteration of the network loop.
Memory usage and fragmentation is something we generally struggle
with, and I really hope this could help with that.

I plan to do some testing with Prosody on Lua 5.5 soon. Unfortunately
we first have to get all our dependencies updated before we can do
real tests, which takes time.

Regards,
Matthew

[Roberto Ierusalimschy]

Thanks for the feedback.

-- Roberto

[Roberto Ierusalimschy]

> Found a typo in the manual:
>
> " Notice that, in a declaration like local x = x, the new x being declared

> is not in scope yet, and so the x in the *left-hand* side refers to the

> outside variable."
> This should be "right-hand".

Thanks.

-- Roberto

[Roberto Ierusalimschy]

> In the C API reference, is there any reason for lua_numbertocstring and
> lua_pushexternalstring prototypes to be parenthesised?

No. We will remove the parentheses.

> Reading about luaL_makeseed triggered a side thought: I know that the VM
> state contains a random seed to harden it against some attacks. But when
> debugging some issues, it would be useful to know (or fix in advance) the
> value used by a given state, and a means to use the same value in a
> subsequent run, so that table hashing can follow the same pattern. Is it
> still time to consider this as an addition to Lua 5.5?

That could be an option to 'lua.c'. (For instance, it could "remove"
this seed.)

-- Roberto

[Roberto Ierusalimschy]

> Seems like additional conceptual problems like what happens to extra
> references to such strings when the variable is closed (especially if
> they're used as table keys) make this complicated (though probably still
> solvable), so choosing not to bother with this is understandable; I just
> wanted to point this out as a possible design direction.

There seems to be a misunderstanding here. There is no such thing as
a "closed string". Strings are not finalized, they are deleted together
with their occasional buffer. If you try to use a closed file, you get
a fair error. If you could try to use a "closed" string, you would get
a C-style Undefined Behavior.

On the other hand, if you can be so sure that the string will not be
used after its "close" point, you don't need to close it: Create it with
no falloc and just reuse the buffer after it being used.

-- Roberto

[Gé Weijers]

On Wed, Jul 2, 2025 at 5:34 PM Andrew Starks <and...@starksfam.org> wrote:

Building the 5.5 beta on macOS (Clang 17, arm64), I got this warning:

lua.c:492:15: warning: cast from 'int (*)(const char *)' to 'l_addhistT' (aka 'void (*)(const char *)') converts to incompatible function type [-Wcast-function-type-mismatch]

Best, 

-- Andrew Starks

I got this one too. I use my own Makefile to build the binaries.

Build the code without -DLUA_USE_READLINE. Lua 5.5 dynamically loads the library if it's available, you don't need the define anymore.

Still a small bug, though.

Gé

[Roberto Ierusalimschy]

> Building the 5.5 beta on macOS (Clang 17, arm64), I got this warning:
> lua.c:492:15: warning: cast from 'int (*)(const char *)' to 'l_addhistT'
> (aka 'void (*)(const char *)') converts to incompatible function type
> [-Wcast-function-type-mismatch]

It seems to be a bug on top of another bug from macOS.

First, it defines add_history with a "wrong" prototype. It provides a
'readline' that should be compatible with Gnu readline but is not.

Second, it warns about an explicit and valid cast. According to the
standard,

ISO/IEC 9899:1999 (E) 6.3.2.3 $8:
A pointer to a function of one type may be converted to a pointer to
a function of another type and back again; the result shall compare
equal to the original pointer.

As it is, it seems I cannot do that without a warning.

-- Roberto

[Roberto Ierusalimschy]

> I'm working with the new lua_pushexternalstring function introduced in
> Lua 5.5.0-beta, aiming to reduce unnecessary memory allocations in my
> application.
>
> However, I've encountered a coredump, and I'm hoping you can help me
> understand if I'm misusing the function.
>

> [...]

Many thanks for the feedback. This is a bug in Lua. When you close the
state, Lua calls all finalizers, and the last finalizer unloads
all dynamically-loaded libraries. So, when the time come to free
the string, lstrfree is not loaded anymore.

-- Roberto

[Sergey Zakharchenko]

Hello Roberto,

Roberto Ierusalimschy <rob...@inf.puc-rio.br>:

> Seems like additional conceptual problems like what happens to extra
> references to such strings when the variable is closed (especially if
> they're used as table keys) make this complicated (though probably still
> solvable), so choosing not to bother with this is understandable; I just
> wanted to point this out as a possible design direction.

There seems to be a misunderstanding here. There is no such thing as
a "closed string".

This is true, correct and understood; however, one might, in some circumstances (like ones outlined by Matthew Wild above) wish to be able to close external strings (offtopic: with some realloc voodoo that I wouldn't recommend, even regular long strings could be meaningfully made closable), which naturally leads to needing something like a closed string; like I said, things then get complicated (most operations would gain special handling to error out "fairly" on such a string) but likely still possible (numbers have NaNs after all). I understand it's likely not worth it, and will continue using userdata for such things.

Best regards,

-- 

DoubleF

[Andrew Starks]

I’m just reading along here, but I’m having trouble understanding why userdata is lacking in your use case. 

- Andrew Starks

On Jul 3, 2025, at 15:59, Sergey Zakharchenko <doublef...@gmail.com> wrote:



--

You received this message because you are subscribed to the Google Groups "lua-l" group.
To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/CADYCxoNg55%3DYm-05%3DUJecbnX%2Bio6w3unNUq9hjDG725XTBeGBA%40mail.gmail.com.

[Marcus Lund]

The cast to l_uint32 is too late for CIST_FRESH when the type of 1u is 16 bit.
This leads to a crash in luaV_execute due to CIST_FRESH having the value zero
instead of 65536.

Replacing the #define with the following fixes the crash:

#define CIST_FRESH (cast(l_uint32, CIST_C) << 1)

[Roberto Ierusalimschy]

Many thanks for the feedback.

-- Roberto

[Marcus Lund]

LUA_REGISTRYINDEX differences on 5.4.8 versus 5.5.0 beta.

Writing the following code (when sizeof(int) equals 2):

printf("LUAI_MAXSTACK: %ld\n", (long) LUAI_MAXSTACK);
printf("LUA_REGISTRYINDEX: %ld\n", (long) LUA_REGISTRYINDEX);

On Lua 5.4 this prints:

LUAI_MAXSTACK: 15000
LUA_REGISTRYINDEX: -16000

On Lua 5.5.0 beta it prints:

LUAI_MAXSTACK: 16383
LUA_REGISTRYINDEX: 48153

This means I am getting warnings when calling e.g. lua_rawsetp:
warning: conversion of unsigned constant value to negative integer [-Wsign-conversion]

LUAI_MAXSTACK is unsigned in luaconf.h:
#if 1000000 < (INT_MAX / 2)
#define LUAI_MAXSTACK 1000000
#else
#define LUAI_MAXSTACK (INT_MAX / 2u)
#endif

Changing it to (INT_MAX/2) it now prints:

LUAI_MAXSTACK: 16383
LUA_REGISTRYINDEX: -17383

which looks more like what #define LUA_REGISTRYINDEX (-LUAI_MAXSTACK - 1000)

intended.

I'm not sure if this is a problem, but I would prefer no warning if possible for e.g. lua_rawsetp.

[Luau Project]

Hi,

On Lua 5.5.0 (beta) source code, I found an issue in the file src/Makefile at line 130:

• it is 'lua54.dll'
• it should be 'lua55.dll'

Link for the patch file: https://pastebin.com/zSJRJN7Y

On Monday, June 30, 2025 at 9:43:16 AM UTC-3 Luiz Henrique de Figueiredo wrote:

Lua 5.5.0 (beta) is now available for testing at
https://www.lua.org/work/lua-5.5.0-beta.tar.gz

The SHA256 checksum is
30897f95fc72565cb6c1792f721ad44e1a42e7ac587f62f7587807b3cbff1645  -

The Git commit ID is
cfce6f4b20afe85ede2182b3df3ab2bfcdb0e692

This is a beta version. Some details may change in the final version.

The main changes in Lua 5.5.0 are listed at
https://www.lua.org/work/doc/#changes

An updated reference manual is included and also available at
https://www.lua.org/work/doc

A test suite is available at
https://www.lua.org/work/lua-5.5.0-tests.tar.gz

[Luiz Henrique de Figueiredo]

> On Lua 5.5.0 (beta) source code, I found an issue in the file src/Makefile at line 130:
>
> it is 'lua54.dll'
> it should be 'lua55.dll'

Thanks for spotting this.

[Roberto Ierusalimschy]

Many thanks for the feedback. Yes, this is a problem. LUA_REGISTRYINDEX
should be a negative value.

-- Roberto

[Roberto Ierusalimschy]

> > which looks more like what #define LUA_REGISTRYINDEX (-LUAI_MAXSTACK - 1000)
> > intended.
> >
> > I'm not sure if this is a problem, but I would prefer no warning if
> > possible for e.g. lua_rawsetp.
>
> Many thanks for the feedback. Yes, this is a problem. LUA_REGISTRYINDEX
> should be a negative value.

But this code is gone now; see commit
59a1adf194efe43741c2bb2005d93d8320a19d14.

-- Roberto

[Marcus Lund]

But this code is gone now; see commit
59a1adf194efe43741c2bb2005d93d8320a19d14.

Indeed, the warning has gone with the latest code (84856879), and CIST_FRESH is working.

Thank you for the fixes.

[Steven]

Is it not possible to use Lua's default seeder with lua_newstate? Technically I can call luaL_makeseed(NULL) because of how it's implemented, but that feels like cheating since its implementation may change without me noticing. Perhaps could luai_makeseed() become luaL_makeseed()? Or at least make it safe to pass NULL in the future? Apologies if this has been answered already, I searched this thread and did not find an answer.

[云风 Cloud Wu]

Steven <sbde...@gmail.com> 于2025年7月20日周日 00:21写道：

>
> Is it not possible to use Lua's default seeder with lua_newstate? Technically I can call luaL_makeseed(NULL) because of how it's implemented, but that feels like cheating since its implementation may change without me noticing. Perhaps could luai_makeseed() become luaL_makeseed()? Or at least make it safe to pass NULL in the future? Apologies if this has been answered already, I searched this thread and did not find an answer.

I wish there was an API that could read out the seed of an existing
lua_State . This makes it easier to generate a lua_State with the same
seed .

[Edoardo]

Regarding the makeseed usage, wouldn't it be possible to have a luaL_newstate accepting a seed directly?

With the added methods, there are 2 ways to pass a custom seed:
* Provide a custom luai_makeseed
* Don't call luaL_newstate and call lua_newstate directly

The first way has a downside, specifically the fact that luai_makeseed is stateless, so it can't be used in a reentrant way by the host (this, by extension, affects luaL_makeseed as well).

The second approach has a downside as well, the fact that by calling lua_newstate directly, the host will also have to take care of repeating the work done by luaL_newstate to set up the extra things in the state, which as lua 5.5 consist in setting the lua_atpanic and lua_setwarnf functions (both of which rely on static functions accessible solely in lauxlib.c, so not usable from outside).

Ideally I'd like to have another variant of luaL_newstate that takes an explicit seed and other than that behaves exactly the same as the current one, and also, if possible, have luai_makeseed be actually stateful and have L passed to it.

[Patrick Donnelly]

On Mon, Jun 30, 2025 at 8:43 AM Luiz Henrique de Figueiredo
<l...@tecgraf.puc-rio.br> wrote:
>
> Lua 5.5.0 (beta) is now available for testing at
> https://www.lua.org/work/lua-5.5.0-beta.tar.gz
>
> The SHA256 checksum is
> 30897f95fc72565cb6c1792f721ad44e1a42e7ac587f62f7587807b3cbff1645 -
>
> The Git commit ID is
> cfce6f4b20afe85ede2182b3df3ab2bfcdb0e692
>
> This is a beta version. Some details may change in the final version.
>
> The main changes in Lua 5.5.0 are listed at
> https://www.lua.org/work/doc/#changes
>
> An updated reference manual is included and also available at
> https://www.lua.org/work/doc
>
> A test suite is available at
> https://www.lua.org/work/lua-5.5.0-tests.tar.gz
>
> All feedback welcome. Thanks.

A few comments:

- I think the manual could be more clear about the scope of for loop
variables. "local to the loop body" is somewhat ambiguous (IMHO).
- For loop variables are now read-only (yay!) but I think the choice
to call these "read-only" is at odds with 3.3.7. Why not use "const"
or "constant"? Or at least say "read-only (const)". I was aware from
other posts that this change was coming but still had to confirm there
wasn't a subtle difference.
- The manual mentions that table references can be a variable (3.2)
but it's not clear that you cannot apply the variable attributes to
table fields (3.3.7) (which are called variables in 3.2).
- table.create is missing in the index
- The `global` keyword and its semantics is quite elegant. I like it.

Great work on this release!

--
Patrick Donnelly

[Edoardo Lolletti]

Regarding the makeseed usage, wouldn't it be possible to have a
luaL_newstate accepting a seed directly?

With the added methods, there are 2 ways to pass a custom seed:
* Provide a custom luai_makeseed
* Don't call luaL_newstate and call lua_newstate directly

The first way has a downside, specifically the fact that luai_makeseed
is stateless, so it can't be used in a reentrant way by the host (this,
by extension, affects luaL_makeseed as well).

The second approach has a downside as well, the fact that by calling
lua_newstate directly, the host will also have to take care of repeating
the work done by luaL_newstate to set up the extra things in the state,
which as lua 5.5 consist in setting the lua_atpanic and lua_setwarnf
functions (both of which rely on static functions accessible solely in
lauxlib.c, so not usable from outside).

Ideally I'd like to have another variant of luaL_newstate that takes an
explicit seed and other than that behaves exactly the same as the
current one, and also, if possible, have luai_makeseed be actually
stateful and have L passed to it.

Il 19/07/2025 18:21, Steven ha scritto:
> Is it not possible to use Lua's default seeder with lua_newstate?
> Technically I can call luaL_makeseed(NULL) because of how it's
> implemented, but that feels like cheating since its implementation may
> change without me noticing. Perhaps could luai_makeseed() become
> luaL_makeseed()? Or at least make it safe to pass NULL in the future?
> Apologies if this has been answered already, I searched this thread and
> did not find an answer.
>
> On Monday, June 30, 2025 at 7:43:16 AM UTC-5 Luiz Henrique de Figueiredo
> wrote:
>
> Lua 5.5.0 (beta) is now available for testing at

> https://www.lua.org/work/lua-5.5.0-beta.tar.gz <https://www.lua.org/
> work/lua-5.5.0-beta.tar.gz>

>
> The SHA256 checksum is
> 30897f95fc72565cb6c1792f721ad44e1a42e7ac587f62f7587807b3cbff1645  -
>
> The Git commit ID is
> cfce6f4b20afe85ede2182b3df3ab2bfcdb0e692
>
> This is a beta version. Some details may change in the final version.
>
> The main changes in Lua 5.5.0 are listed at

> https://www.lua.org/work/doc/#changes <https://www.lua.org/work/doc/
> #changes>

>
> An updated reference manual is included and also available at

> https://www.lua.org/work/doc <https://www.lua.org/work/doc>

>
> A test suite is available at

> https://www.lua.org/work/lua-5.5.0-tests.tar.gz <https://
> www.lua.org/work/lua-5.5.0-tests.tar.gz>

>
> All feedback welcome. Thanks.
> --lhf
>

> --
> You received this message because you are subscribed to the Google
> Groups "lua-l" group.
> To unsubscribe from this group and stop receiving emails from it, send

> an email to lua-l+un...@googlegroups.com <mailto:lua-
> l+unsu...@googlegroups.com>.

> To view this discussion visit https://groups.google.com/d/msgid/lua-

> l/206eb0ff-dfb8-400a-9eef-a914e212e633n%40googlegroups.com <https://
> groups.google.com/d/msgid/lua-l/206eb0ff-dfb8-400a-9eef-
> a914e212e633n%40googlegroups.com?utm_medium=email&utm_source=footer>.

[ppp vvv]

clang makes a couple warnings:

lua-5.5.0-beta\src\lparser.c:1821:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]

    case RDKTOCLOSE:
      luaK_semerror(ls, "global variables cannot be to-be-closed");
      return kind;         //      break;  /* to avoid warnings */

lua-5.5.0-beta\src\ltable.c:59:8: warning: variable length array folded to constant array as an extension [-Wgnu-folding-constant]

enum { Limbox_padding_size = offsetof(Limbox_aux, follows_pNode) };      //force compile time constant

typedef union {
  Node *lastfree;
  char padding[Limbox_padding_size];     //  char padding[offsetof(Limbox_aux, follows_pNode)];

} Limbox;

[Sainan]

> lua-5.5.0-beta\src\lparser.c:1821:1: warning: non-void function does not return a value in all control paths [-Wreturn-type]

Curious, that. luaK_semerror is already marked as l_noret, so Clang should know this function never returns, closing that the control path, so to say. Might be that l_noret is not correctly set in your configuration?

-- Sainan

[Roberto Ierusalimschy]

> clang makes a couple warnings:

Thanks for the feedback.

> lua-5.5.0-beta\src\lparser.c:1821:1: warning: non-void function does not
> return a value in all control paths [-Wreturn-type]
>
> case RDKTOCLOSE:
> luaK_semerror(ls, "global variables cannot be to-be-closed");
> return kind; // break; /* to avoid warnings */

Just to make sure: You are posting the warning followed by code
already changed, not the code that created the warning; is that right?

> lua-5.5.0-beta\src\ltable.c:59:8: warning: variable length array folded to
> constant array as an extension [-Wgnu-folding-constant]
>
> enum { Limbox_padding_size = offsetof(Limbox_aux, follows_pNode) };
> //force compile time constant
>
> typedef union {
> Node *lastfree;
> char padding[Limbox_padding_size]; // char
> padding[offsetof(Limbox_aux, follows_pNode)];
> } Limbox;

This seems to be a compiler bug. According to the ISO-C standard,
the macro offsetof "expands to an integer constant expression",
so its use should not create a variable length array. Moreover,
if offsetof could not be used for array sizes, it could not be
used for initialization in enums either, as it asks for the same
integer constant expressions: "An integer constant expression is used
to specify the size of a bit-field member of a structure, the value of
an enumeration constant, the size of an array, or the value of a case
constant." If it is good for the value of an enumeration constant,
it should be good for the size of an array.

-- Roberto

[ppp vvv]

yes, l_noret is void for clang as it is neither __GNUC__ nor _MSC_VER > 1200

i should redefine it as void __attribute__((noreturn)) manually or pretend to be __GNUC__.

>Just to make sure: You are posting the warning followed by code

already changed, not the code that created the warning; 

yes, it is proposed fix i made to get rid of that warnings and //commented is the original code.

even if the function is [[noreturn]] i guess additional "return kind;" instead of break; or at the end of the getglobalattribute function, instead of "default: return kind;" case

would probably add just additional couple bytes to the code size but make all the compilers that unaware of noreturn happy.

offsetof could be used as array size, but probably compiler considers himself too smart, and could make VLA when it sees inside [] anything else than constant integer literal, and only afterwards decides to optimize it as its size looks like constant.

and if is implemented just as macro #define offsetof(s, m) ((size_t)&(((s *)0)->m)) and if there is (for example) volatile keyword involved i'm not that sure how "constant" this value is. 

so i admit there could be some ambiguity with VLA, but with enum hack there is no way to make VLA out of enum.

regards,

Pavel

суббота, 9 августа 2025 г. в 18:26:38 UTC+2, Roberto Ierusalimschy:

[Sainan]

Hmm, in my experience, Clang usually tries to immitate GCC and/or MSVC, but I suppose Clang is also big enough to deserve being added to the ifdefs.

-- Sainan

[Roberto Ierusalimschy]

> offsetof could be used as array size, but probably compiler considers
> himself too smart, and could make VLA when it sees inside [] anything else
> than constant integer literal, and only afterwards decides to optimize it
> as its size looks like constant.
> and if is implemented just as macro #define offsetof(s, m) ((size_t)&(((s
> *)0)->m)) and if there is (for example) volatile keyword involved i'm not
> that sure how "constant" this value is.
> so i admit there could be some ambiguity with VLA, but with enum hack there
> is no way to make VLA out of enum.

There is no ambiguity here. The C language specification has a
well-defined concept of *integer constant expression*. These are not
optimizations: It is a language construct that defines what can be used
in array sizes and enum initializations (plus a few other places, such
as switch cases). The specification clearly says that offsetof is an
integer constant expression. If clang doesn't accept it, it is breaking
its contract with the standard. That is not something for the compiler
to decide.

-- Roberto

[Gottfried Leibniz]

On 8/9/2025 6:59 PM, 'Sainan' via lua-l wrote:
> Hmm, in my experience, Clang usually tries to immitate GCC and/or MSVC, but I suppose Clang is also big enough to deserve being added to the ifdefs.

I suspect OP is compiling with "-fgnuc-version=0", which seems like a
non-standard configuration (a shell alias or some version of LLVM that
zeros this by default (?)).

Roberto, if you are interested in other weird configurations (unlikely),
compiling w/ Nvidia's C/C++ compiler will emit:

"lfunc.c", line 199: warning: variable "upl" was set but never used
[set_but_not_used]
StkId upl; /* stack index pointed by 'uv' */

Thanks

[Roberto Ierusalimschy]

> Roberto, if you are interested in other weird configurations (unlikely),
> compiling w/ Nvidia's C/C++ compiler will emit:
>
> "lfunc.c", line 199: warning: variable "upl" was set but never used
> [set_but_not_used]
> StkId upl; /* stack index pointed by 'uv' */

That is not weird; the warning seems quite noncontroversial. What is
weird is that no other compiler gave this warning. Thanks for the
feedback.

-- Roberto

[Gé Weijers]

On Sat, Aug 9, 2025 at 2:49 PM ppp vvv <pv15...@gmail.com> wrote:

yes, l_noret is void for clang as it is neither __GNUC__ nor _MSC_VER > 1200

i should redefine it as void __attribute__((noreturn)) manually or pretend to be __GNUC__.

Which version of clang are you using? I'm compiling the code on an Apple machine which has the following version:

Apple clang version 17.0.0 (clang-1700.0.13.5)

Target: arm64-apple-darwin24.6.0 

I don't see any warning even though I've explicitly passed -Wreturn-type to the compiler.

clang usually defines __GNUC__. When I compile this code:

#ifdef __GNUC__
char f[1.3];
#endif

I get an error about a non-integer array bound, so it's definitely defined.

you can get a list of all macros defined by the compiler:  clang -E -dM afile.c

Gé

[Gottfried Leibniz]

On 8/10/2025 5:49 PM, Roberto Ierusalimschy wrote:
> That is not weird; the warning seems quite noncontroversial.

Definitely.

Few other comments/nitpicks I have noticed:

1. In lopcodes.h (and ljumptab.h) OP_SHL is before OP_SHR. However, in
lvm.c 'vmcase(OP_SHR)' is placed before 'vmcase(OP_SHL)': these are the
only opcodes in the VM dispatch statement not laid out in strictly
increasing integer order.

2. PrintConstant in luac.c could probably use 'lua_number2str' instead
of 'sprintf(buff,LUA_NUMBER_FMT,...)'. Otherwise, a double-promotion
warning may trigger on different luaconf.h configurations, e.g.,
LUA_32BITS.

3. Given that lua_rawlen enters the Lua core (luaH_getn), where the
Table can be modified (lenhint), should the lua_rawlen invocation be
wrapped with lua_{lock,unlock}?

4. In `#define obj2gco(v)` is the `(v)->tt >= LUA_TSTRING,` check
technically correct? Or should the variant bits be stripped from
`(v)->tt`.

Thanks

[Tom Sutcliffe]

Minor issue in the manual, in section 2.2 (from https://www.lua.org/work/doc/manual.html#2.2)

"Notice that, in a declaration like local x = x, the new x being declared is not in scope yet, and so the x in the left-hand side refers to the outside variable"

Should that say *right*-hand side?

Cheers,

Tom

On 30 Jun 2025, at 13:43, Luiz Henrique de Figueiredo <l...@tecgraf.puc-rio.br> wrote:

Lua 5.5.0 (beta) is now available for testing at
https://www.lua.org/work/lua-5.5.0-beta.tar.gz

The SHA256 checksum is
30897f95fc72565cb6c1792f721ad44e1a42e7ac587f62f7587807b3cbff1645  -

The Git commit ID is
cfce6f4b20afe85ede2182b3df3ab2bfcdb0e692

This is a beta version. Some details may change in the final version.

The main changes in Lua 5.5.0 are listed at
https://www.lua.org/work/doc/#changes

An updated reference manual is included and also available at
https://www.lua.org/work/doc

A test suite is available at
https://www.lua.org/work/lua-5.5.0-tests.tar.gz

All feedback welcome. Thanks.
--lhf

--
You received this message because you are subscribed to the Google Groups "lua-l" group.

To unsubscribe from this group and stop receiving emails from it, send an email to lua-l+un...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/lua-l/12df2e1b-3ab3-4903-866a-7745024b862cn%40googlegroups.com.

[Steven]

I thought so too, but then I thought maybe they meant to imply "after the assignment completes" which would effectively mean the same thing.

To view this discussion visit https://groups.google.com/d/msgid/lua-l/73495012-CC79-4436-80A4-29133395900C%40me.com.

[Roberto Ierusalimschy]

> Minor issue in the manual, in section 2.2 (from https://www.lua.org/work/doc/manual.html#2.2)
>
> "Notice that, in a declaration like local x = x, the new x being declared is not in scope yet, and so the x in the left-hand side refers to the outside variable"
>
> Should that say *right*-hand side?

Yes, thanks. (I think that was already reported a few days ago.)

-- Roberto

[Roberto Ierusalimschy]

> Few other comments/nitpicks I have noticed:
>

> [...]

Many thanks for the feedback. We will look into them.

-- Roberto