On Wed, 14 Sep 2005, Paul Eggert wrote: > "Joel E. Denny" <[EMAIL PROTECTED]> 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
