Re: %destructor can leak the lookahead

[Paul Eggert]

Akim Demaille <address@hidden> writes:

>  > Is it that we need to destroy the semantic value of the error token
>  > itself, before executing the first code snippet quoted above?
>
> Hm, I never thought about this possibility.  Can you really pass some
> semantic value to error?

I checked, and POSIX doesn't explicitly rule it out, but it doesn't
say how it'd be done either.  I guess it's not part of standard Yacc.
Sorry about the confusion.

> how can you type it...

With a %token declaration, presumably.  You are allowed to say "%token
error 37".  So I guess you'd say "%token <string> error 37".  It might
be useful to have this as an extension, e.g., a variant of YYERROR
that lets you pass a semantic value back.  (But for now let's not
worry about this.  :-)

>  > * the stack overflows, and the user-defined yyoverflow macro refuses
>  >   to extend the stack.  This does a YYABORT without invoking destructors.
>
> You're right, that should be handled too.
>
>  > * The user code invokes YYERROR.  This pops "yylen" items without
>  >   destroying them.
>
> Definitely.
>
> Maybe we should also free the stack and lookahead (but not $$) when
> YYACCEPT is called.

Yes, that sounds right.

> I think we should factor YY_SYMBOL_PRINT calls into yydestruct itself.

Sounds reasonable to me.

> --- data/yacc.c 2 Sep 2004 14:27:02 -0000 1.65
> +++ data/yacc.c 3 Sep 2004 08:57:48 -0000
> @@ -1209,6 +1209,9 @@
>  | yyabortlab -- YYABORT comes here.  |
>  `-----------------------------------*/
>  yyabortlab:
> +  YY_SYMBOL_PRINT ("Error: discarding lookahead", yytoken, &yylval, &yylloc);
> +  yydestruct (yytoken, &yylval]b4_location_if([, &yylloc])[);
> +  yychar = YYEMPTY;
>    yyresult = 1;
>    goto yyreturn;
>  

How do we know that yytoken is valid here, and can be destroyed?
Might it not be the case that yychar == YYEMPTY as we pass yyabortlab?
Similarly for the other parsers.

Other than that, I didn't see any problem (except that the other
memory leaks mention above still remain -- do you have time to look
into them as well?).