[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Bug: long strings with REALLY long delimiters…
- From: nobody <nobody+lua-list@...>
- Date: Wed, 12 Dec 2018 22:55:15 +0100
…like [===…===[a]===…===] cause all sorts of weird behavior (incl.
crashes) in 5.3.x / 5.4 (git HEAD). Try
local eqs = ("="):rep(0x3ffffffe)
local code = "return ["..eqs.."[a]"..eqs.."]"
It might segfault, it might print a huge number instead of 1 (or, minus
the '#', print 'a]===…===]<<garbage>>' instead of a single 'a').
And with ASAN (-fsanitize=address) you get told more gory details, like
that it's trying to do a 0x1_0000_0001-long read (4GiB plus 1 Byte… that
read size is stable over the next couple extra ='s).
I haven't deeply looked into this, from a cursory glance it might be
(partly?) caused by the separator length being tracked in an `int`,
which affects (in 5.4/git)
llex.c:251: skip_sep (return, locvar on next line)
llex.c:264: read_long_string (funarg)
llex.c:447: llex (locvar)
A quick test (int --> ptrdiff_t in those 4 places) _seems_ to fix it,
but there might be more…