Re: user destructor for unresolved GLR semantic value

[Joel E. Denny]

On Wed, 24 Aug 2005, Joel E. Denny wrote:

> Following the test case is a patch relative to my latest cvs co.  I merely
> added another parameter to yydestruct() to specify whether any user
> destructor should actually be invoked.  For tokens, the yydestruct()
> caller always specifies yytrue.  Otherwise, the yydestruct() caller passes
> the yyGLRState yyresolved member.  I also modified the definition of
> b4_yydestruct_generate() in "c.m4" in such a way that "yacc.c" does not
> need to be modified.

I botched this patch in numerous ways:

1. I modified b4_yydestruct_generate() incorrectly by leaving off the
yyuser_destructor param name.  In the patch, replace this line:

  +    [[yybool yyuser_destructor]]]))[

with this one:

  +    [[yybool yyuser_destructor], [yyuser_destructor]]]))[

2. yydestruct() indirectly invokes the user-supplied YYPRINT() regardless
of the value of yyuser_destructor.  YYPRINT() may access the semantic
value.  I'm not sure what to do here.  Should the required interface of
YYPRINT() be changed to accept a boolean parameter similar to my
yyuser_destructor?  Should YYPRINT() not be used in this case?

3. Although my patch prevents the potential seg fault, I believe there's
still a potential memory leak that it does not address.  That is, if
!yyresolved, the yyGLRState stores a list of yySemanticOption's.  Each
yySemanticOption has a yystate member.  That yystate is the last state in
a RHS potentially containing many semantic values.  For this case of an
error during a split stack, I cannot find where the user destructors are
called for those semantic values.  Based on the `well-formed' comment at
`yyreturn:', I wonder if this might be a conscious decision.  I'll
continue to explore this, but does anyone already know what's going on?

Joel