<feed xmlns='http://www.w3.org/2005/Atom'>
<title>lua/lobject.c, branch v5.5.1</title>
<subtitle>A mirror of https://github.com/lua/lua
</subtitle>
<id>https://git.lua4.win/lua/atom?h=v5.5.1</id>
<link rel='self' href='https://git.lua4.win/lua/atom?h=v5.5.1'/>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/'/>
<updated>2025-07-29T14:50:20+00:00</updated>
<entry>
<title>Added some casts for 32-bit machines</title>
<updated>2025-07-29T14:50:20+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-07-29T14:50:20+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=c33bb08ffe04f24e09571b59eed3c9b59b622d91'/>
<id>urn:sha1:c33bb08ffe04f24e09571b59eed3c9b59b622d91</id>
<content type='text'>
When both 'int' and 'l_obj' have 32 bits, an unsigned int needs a
cast to be assigned to 'l_obj'. (As long as 'l_obj' can count the
total memory used by the system, these casts should be safe.)
</content>
</entry>
<entry>
<title>Randomness added to table length computation</title>
<updated>2025-07-18T19:18:30+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-07-18T19:18:30+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=303f4155593721dfd57dadc6e56122e465ce9efb'/>
<id>urn:sha1:303f4155593721dfd57dadc6e56122e465ce9efb</id>
<content type='text'>
A bad actor could fill only a few entries in a table (power of twos in
decreasing order, see tests) and produce a small table with a huge
length. If your program builds a table with external data and iterates
over its length, this behavior could be an issue.
</content>
</entry>
<entry>
<title>Details (comments)</title>
<updated>2025-07-07T18:02:09+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-07-07T18:02:09+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=03d672a95cfd287855b373587f3975165eab9e02'/>
<id>urn:sha1:03d672a95cfd287855b373587f3975165eab9e02</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Janitorial work on casts</title>
<updated>2025-05-08T18:18:57+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-05-08T18:18:57+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=7ade1557627cf3f09c23c892ee227b7386f28414'/>
<id>urn:sha1:7ade1557627cf3f09c23c892ee227b7386f28414</id>
<content type='text'>
</content>
</entry>
<entry>
<title>Using 'l_uint32' for unicode codepoints in scanner</title>
<updated>2025-05-08T15:49:39+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-05-08T15:49:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=d827e96f33056bcc0daca0c04b3273604f9d5986'/>
<id>urn:sha1:d827e96f33056bcc0daca0c04b3273604f9d5986</id>
<content type='text'>
'l_uint32' is enough for unicode codepoints (versus unsigned long),
and the utf-8 library already uses that type.
</content>
</entry>
<entry>
<title>Details</title>
<updated>2025-02-26T14:29:54+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-02-26T14:29:54+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=ceac82f78be8baeddfa8536472d8b08df2eb7d49'/>
<id>urn:sha1:ceac82f78be8baeddfa8536472d8b08df2eb7d49</id>
<content type='text'>
Comments, small changes in the manual, an extra test for errors in
error handling, small changes in tests.
</content>
</entry>
<entry>
<title>Fixed conversion warnings from clang</title>
<updated>2025-01-14T19:24:46+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2025-01-14T19:24:46+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=3cdd49c94a8feed94853ba3a6adaa556fb34fd8d'/>
<id>urn:sha1:3cdd49c94a8feed94853ba3a6adaa556fb34fd8d</id>
<content type='text'>
Plus some other details. (Option '-Wuninitialized' was removed from
the makefile because it is already enabled by -Wall.)
</content>
</entry>
<entry>
<title>New function 'lua_numbertostrbuff'</title>
<updated>2024-10-23T20:16:17+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2024-10-23T20:16:17+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=e3ce88c9e850b7e79751083014699c5eae1bff31'/>
<id>urn:sha1:e3ce88c9e850b7e79751083014699c5eae1bff31</id>
<content type='text'>
It converts a Lua number to a string in a buffer, without creating
a new Lua string.
</content>
</entry>
<entry>
<title>No errors in 'luaO_pushvfstring'</title>
<updated>2024-09-20T18:56:39+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2024-09-20T18:56:39+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=20d42ccaaed9a84783d548d76633a5a38f0091f1'/>
<id>urn:sha1:20d42ccaaed9a84783d548d76633a5a38f0091f1</id>
<content type='text'>
Any call to 'va_start' must have a corresponding call to 'va_end';
so, functions called between them (luaO_pushvfstring in particular)
cannot raise errors.
</content>
</entry>
<entry>
<title>Towards no errors in 'luaO_pushvfstring'</title>
<updated>2024-09-20T15:21:11+00:00</updated>
<author>
<name>Roberto Ierusalimschy</name>
<email>roberto@inf.puc-rio.br</email>
</author>
<published>2024-09-20T15:21:11+00:00</published>
<link rel='alternate' type='text/html' href='https://git.lua4.win/lua/commit/?id=70d6975018c1f2b8ce34058a4d54a28a3fafca66'/>
<id>urn:sha1:70d6975018c1f2b8ce34058a4d54a28a3fafca66</id>
<content type='text'>
Any call to 'va_start' must have a corresponding call to 'va_end';
so, functions called between them (luaO_pushvfstring in particular)
cannot raise errors.
</content>
</entry>
</feed>
