Is this an LPeg bug? (was Re: Lua 5.3.4 and LPeg 1.0.1 dumped core on me)

[Sean Conner <sean@...>]

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?

  -spc