Table length evaluations --> Lua 5.5 vs. Lua 5.4

[Kritzel Kratzel]

While porting lua-cjson to Lua 5.5, I encountered a test case failure. It appears that Lua 5.5 handles table length evaluation differently than previous versions, especially regarding tables with holes:

[C:\...\tests]> lua -e "print(_VERSION); t={nil,true}; print(#t)"
Lua 5.5
0

[C:\...\tests]> C:\Apps\OneLuaPro-5.4.8.3-x64\bin\lua.exe -e "print(_VERSION); t={nil,true}; print(#t)"
Lua 5.4
2

Bug or feature?

Regards,

KK

[Sainan]

Already discussed: https://groups.google.com/g/lua-l/c/pOH68GYtDgw/m/BFAORSs5DAAJ

-- Sainan

[Błażej Roszkowski]

It seems there are still bugs. Comment in C source says "or 0 if t[1] is absent" but

for {nil, 1, 1, 1} the # yields 4 (due to *lenhint being 2 so 1 is never checked).

On Sun, 15 Feb 2026 at 12:15, 'Sainan' via lua-l <lu...@googlegroups.com> wrote:

Already discussed: https://groups.google.com/g/lua-l/c/pOH68GYtDgw/m/BFAORSs5DAAJ

-- Sainan

--
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/-cUyh55EpmfwvcYw_VudoxV8qT60SexwLNx36uzfDGDSDOS2-GGp4Kqh0lQxxX7NARzhur1LZMlcyutRiYLuQ-KnvKOFizgH0wAA9Bks82E%3D%40calamity.inc.

[Kritzel Kratzel]

Indeed:

[C:\...\tests]> lua -e "print(_VERSION); t={nil,true}; print(#t)"
Lua 5.5
0

[C:\...\tests]> lua -e "print(_VERSION); t={nil,true,true}; print(#t)"
Lua 5.5
0

[C:\...\tests]> lua -e "print(_VERSION); t={nil,true,true,true}; print(#t)"
Lua 5.5
4

[C:\...\tests]> lua -e "print(_VERSION); t={nil,true,true,true,true}; print(#t)"
Lua 5.5
5

[C:\...\tests]> lua -e "print(_VERSION); t={nil,true,true,true,true,true}; print(#t)"
Lua 5.5
6

I mean, is the the intented behavior?

[Luiz Henrique de Figueiredo]

> It appears that Lua 5.5 handles table length evaluation differently than previous versions, especially regarding tables with holes:

Taking the length of a table with holes is undefined behavior.

[Luther Thompson]

On 2/15/26 07:04, Błażej Roszkowski wrote:
> It seems there are still bugs. Comment in C source says "or 0 if t[1]
> is absent" but
> for {nil, 1, 1, 1} the # yields 4 (due to *lenhint being 2 so 1 is
> never checked).

I don't know where that comment is, but if it's like the documentation
at https://www.lua.org/manual/5.5/manual.html#3.4.7, it's merely part of
the definition of a border. Since the # result can be any border, it
won't always be 0 if there are other borders in the table.

Luther

[Błażej Roszkowski]

The comment in ltable.c line 1291 above luaH_getn:

** Try to find a border in table 't'. (A 'border' is an integer index
** such that t[i] is present and t[i+1] is absent, or 0 if t[1] is absent,
** or 'maxinteger' if t[maxinteger] is present.)

The "or 0 if t[1] is absent" makes it sound like it took precedence over the first definition.

OTOH the documentation is correct and even mentions if there's more

than one border (non-sequence table) then any can be returned.

--
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/2b9ef29a-a816-40dd-b758-afe01c07ca07%40gmail.com.