Re: Bug: long strings with REALLY long delimiters…

[Roberto Ierusalimschy <roberto@...>]

> _Maybe_, although long comments didn't cause problems in my tests (as in
> it properly skipped the comment and ASAN didn't complain.)  And I think
> it's the computation in read_long_string just below where it goes
> 
> seminfo->ts = luaX_newstring(ls, luaZ_buffer(ls->buff) + (2 + sep),
>                                  luaZ_bufflen(ls->buff) - 2*(2 + sep));
> 
> because it's only ++'ing in skip_sep and 0x3ffffffe still fits (tho
> yours doesn't).

Right. More exactly, the overflow is in the computation 2*(2 + sep).
With 'sep' being 0x3ffffffe, this expression results in 0x80000000,
which wraps to a negative number and then is added (instead of being
subtracted) to the buffer length.

Strangely, neither gcc nor clang, with option '-ftrapv', detected
this overflow.

Instead of using a larger type to count 'sep', it seems easier to just
limit the maximum number of '=' in a long bracket. I don't think people
will mind a limit of 1000.

-- Roberto