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
