Re: duplicated user destructor for lookahead

[Joel E. Denny]

On Wed, 14 Sep 2005, Paul Eggert wrote:

> "Joel E. Denny" <address@hidden> writes
> in <http://lists.gnu.org/archive/html/bison-patches/2005-08/msg00035.html>:
>
> > I added a bool yytoken_shifted alongside yytoken.  It tracks whether the
> > parser has shifted yytoken onto any stack yet.  Like yytoken, it is a
> > local variable in yyparse().  There's also a yytoken_shiftedp like
> > yytokenp in yyGLRStack.  The parser does not call the user destructor for
> > the lookahead if yytoken_shifted.
>
> Thanks for the test case and for the proposed patch.  But even with
> the patch, if the token is shifted onto two stacks before memory is
> exhausted, won't its associated value be freed twice?  (Sorry, I don't
> quite follow the logic.)

User destructors are called on only one stack.  See:

  http://lists.gnu.org/archive/html/bison-patches/2005-08/msg00029.html

> Let's put it another way.  Here's a bogus patch that I just tried; can
> you please explain a little why it's bogus?
>
> --- glr.c.~1.120.~    2005-09-11 22:28:02.000000000 -0700
> +++ glr.c     2005-09-14 15:59:48.000000000 -0700
> @@ -1806,6 +1806,7 @@ yyprocessOneStack (yyGLRStack* yystack,
>           {
>             YYDPRINTF ((stderr, "On stack %lu, ", (unsigned long int) yyk));
>             YY_SYMBOL_PRINT ("shifting", *yytokenp, yylvalp, yyllocp);
> +           *yytokenp = YYEMPTY;
>             yyglrShift (yystack, yyk, yyaction, yyposn+1,
>                         *yylvalp, yyllocp);
>             YYDPRINTF ((stderr, "Stack %lu now in state #%d\n",

Because the lookahead needs to remain available to be shifted onto the
other stacks.

Joel