| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
| |
It apparently requires passing V variable explicitly.
Fixes: fe59b46ca7e0 ("lua: include version number in installed files")
Reported-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
| |
|
|
|
|
| |
This will allow installing Lua 5.1 and newer versions at the same time.
Signed-off-by: Rafał Miłecki <rafal@milecki.pl>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lua's LNUM patch currently doesn't parse properly certain numbers as
it's visible from the following simple tests.
On x86_64 host (stock Lua 5.1.5, expected output):
$ /usr/bin/lua -e 'print(0x80000000); print(0x80000000000); print(0x100000000)'
2147483648
8796093022208
4294967296
On x86_64 host:
$ staging_dir/hostpkg/bin/lua -e 'print(0x80000000); print(0x80000000000); print(0x100000000)'
-2147483648
0
0
On x86_64 target:
$ lua -e 'print(0x80000000); print(0x80000000000); print(0x100000000)'
-2147483648
0
0
On ath79 target:
$ lua -e 'print(0x80000000); print(0x80000000000); print(0x100000000)'
-2147483648
8796093022208
4294967296
It's caused by two issues fixed in this patch, first issue is caused by
unhadled strtoul overflow and second one is caused by the cast of
unsigned to signed Lua integer when parsing from hex literal.
Run tested on:
* Zidoo Z9S with RTD1296 CPU (aarch64_cortex-a53)
* qemu/x86_64
* qemu/armvirt_64
* ath79
Signed-off-by: Liangbin Lian <jjm2473@gmail.com>
[commit subject/message touches, fixed From to match SOB, fixed another
unhandled case in luaO_str2i, host Lua, package bump]
Signed-off-by: Petr Štetiar <ynezz@true.cz>
|
| |
|
|
|
|
| |
Refresh patches to tidy up fuzz. No functional changes
Signed-off-by: Kevin Darbyshire-Bryant <ldir@darbyshire-bryant.me.uk>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This was found while investigating why luarocks does not work. It was
traced to a quite old lnum patch for 5.1.3. I compared against the
latest 5.1.4 patch - https://github.com/LuaDist/lualnum and discovered
the lessthan/lessequal evaluation was not falling through to the
call_orderTM (tag methods).
I have tested LuCI (simple tests) and used the following lua code to
validate the patch (both host and target patches supplied): -
> local my_mt = {
> __eq = function(v1, v2)
> print("__eq")
> return false
> end,
> __lt = function(v1, v2)
> print("__lt")
> return false
> end,
> __le = function(v1, v2)
> print("__le")
> return false
> end
> }
>
> function get_my(vstring)
> local my = {}
> my.string = vstring;
> setmetatable(my, my_mt);
> return my;
> end
>
> local a = get_my("1.0")
> local b = get_my("1.0")
>
> local eq_works = a == b;
> local lt_works = a < b;
> local gt_works = a > b;
>
> local lte_works = a <= b;
> local gte_works = a >= b;
Without the patch the following error will be presented: -
“attempt to compare two table values”
Signed-off-by: David Thornley <david.thornley@touchstargroup.com>
|
| |
|
|
|
|
| |
Signed-off-by: Steven Barth <steven@midlink.org>
SVN-Revision: 46036
|
| |
|
|
|
|
| |
Signed-off-by: Felix Fietkau <nbd@openwrt.org>
SVN-Revision: 45509
|
|
|
Signed-off-by: John Crispin <blogic@openwrt.org>
SVN-Revision: 37007
|
