LPEG bugs (was Re: LPEG documentation needs more clarification)

[Sean Conner <sean@...>]

Back from November, was this from you:

> > I replied:
> > It was thus said that the Great Andrew Gierth once stated:
> > > >>>>> "Andrew" == Andrew Gierth <andrew@tao11.riddles.org.uk> writes:
> > > 
> > >  Andrew> This code thinks it can create an anonymous group capture with
> > >  Andrew> no valid .s pointer (to contain the results of a match-time
> > >  Andrew> capture). I _think_ the failure is normally hidden by the fact
> > >  Andrew> that base[0] is _usually_ a reuse of the same Capture that was
> > >  Andrew> used for the match-time capture itself - except that the array
> > >  Andrew> of Capture structures might get reallocated between the two
> > >  Andrew> uses, without preserving the old value of the (now unused)
> > >  Andrew> Capture.
> > > 
> > > Further analysis shows that my original idea was wrong; correct
> > > substitution _requires_ that the value of base[0].s actually be
> > > preserved rather than initialized in adddyncaptures. So the fix seems to
> > > be to ensure that it is preserved across expansion of the captures
> > > array:
> > > 
> > > --- lpvm.c.orig 2018-11-10 09:37:29 UTC
> > > +++ lpvm.c
> > > @@ -311,7 +311,7 @@ const char *match (lua_State *L, const c
> > >            if (fr + n >= SHRT_MAX)
> > >              luaL_error(L, "too many results in match-time capture");
> > >            if ((captop += n + 2) >= capsize) {
> > > -            capture = doublecap(L, capture, captop, n + 2, ptop);
> > > +            capture = doublecap(L, capture, captop, n + 1, ptop);
> > >              capsize = 2 * captop;
> > >            }
> > >            /* add new captures to 'capture' list */
> > > 
> > > By telling doublecap that one less Capture structure is "new", we make
> > > it preserve one more of the existing values, which is the one we need.
> > > 
> > > This patch fixes both my testcase and the original report, as far as I
> > > can tell.
> > 
> >   Just in case Roberto & Co. did not see this thread---is this an actual bug
> > in LPeg?
> 
> It seems so.

and now this:

> > What I did not expect was the 2,900 C callstack entries this produced (thus
> > causing the crash).
> 
> You are doing a kind of lazy evaluation. Each new definition of 'count'
> depends on the previous one. When LPeg goes on to evaluate the last
> definition, it needs to evaluate (using recursion in the C code)
> the previous one, and so and so. So, you have many recursion levels
> multiplied by the number of intermediate functions inside the indirect
> recursion.
> 
> Nevertheless, this is a bug in LPeg. It should limit its recursion level
> and give a decent error. (This is always a nightmare in C.)

  Any chances for these bugs to be fixed and included in a new version of
LPEG?

  -spc