Re: %destructor documentation not quite right...

[Steve Murphy]

Joel--

Many thanks for your response. It's cleared up my thinking somewhat.

BTW-- I got a segfault when I fed bison this nonsense:

%destructor { free($$);} else {printf("Cleanup destructor called for str
\n");} } word word_list goto_word word3_list includedname

I deserve to have a crash because of this stupidity, but... but... Well,
thought you'd like to know...

I missed the part about the start token, which was my downfall. So I
removed it from the %destructor list. Then, I got rid of the 'C' test,
and all looks well. Just a thought, but if the error processing tosses
the start token? I guess it won't matter much; won't be much left to
throw away...

It appears that "warning: unused value" and "warning: unset value"
checks have been added to 2.1a (or I've been missing them
previously!!!), which I REALLY LIKE! found & fixed some possible bugs in
my grammar because of this, and I appreciate the help.

murf




On Sat, 2006-04-22 at 00:03 -0400, Joel E. Denny wrote:
> On Fri, 21 Apr 2006, Steve Murphy wrote:
> 
> > I read the manual entry (for the first time) on the %destructor
> > directive, and thought, "Wow! Fantastic! Now I can get rid of the
> > 'syntax err == leaked memory' problem!!!!
> > 
> > But I encountered some bumps in the road!
> 
> I recommend you try out 2.1a, which you can download from:
> 
>   ftp://alpha.gnu.org/gnu/bison/
> 
> We've made some %destructor changes since 2.1, and the documentation no 
> longer refers to %destructor as an experimental feature.
> 
> > If no syntax errs occur, I already have mechanisms to free the 
> > structs that yyparse allocated, AFTER THE APP IS FINISHED USING THEM.
> > 
> > But, I'm getting calls to yydestruct even when there are no errors.
> 
> Did you notice that Bison calls it for the start symbol?  If you're 
> building a tree and you've defined a cascading destructor, this might wipe 
> out many more values.
> 
> > I've included the .info text for the bison manual below... I do not see
> > it clearly stated below that just about ALL tokens will be "discarded"
> > during the parsing process,
> 
> Because it's not true.  Once Bison invokes one of your semantic actions, 
> it will not directly invoke destructors for any of that production's RHS 
> symbols.  This was almost true in 2.1 (YYABORT and YYACCEPT being the 
> notable exceptions), and it should be completely true in 2.1a.  Here's an 
> important quote from the 2.1a documentation:
> 
>   As a rule of thumb, destructors are invoked only when user actions 
>   cannot manage the memory.
> 
> > and those which are discarded because of
> > errors will have a yymsg argument to yydestruct of "Error:
> > discarding.../popping", and those which are discarded because of who-
> > knows-what-other-reason (maybe via reduce?) begin with "Cleanup:
> > discarding.../popping". So, if I make my code look like this:
> > 
> > %destructor {  if (yymsg[0] != 'C') free_value($$); }  start expr TOKEN
> >                                             TOK_COND TOK_COLONCOLON ...
> 
> I recommend you don't depend on this.  yymsg is not documented for access 
> by the user.
> 
> > Even worse, the text below seems to imply that yydestruct will only be
> > called in association with error processing
> 
> It mentions destruction of the start symbol value as well.
> 
> > , yet the code seems to
> > indicate that the calls for "Cleanup" purposes is not a typo, but
> > carefully designed to allow the user (me) the option of freeing any or
> > all memory as the parser processes it.
> 
> No.  Bison uses that `Cleanup' prefix for any destructor calls that don't 
> occur during error recovery, in which case there's an `Error' prefix 
> instead.  For example, YYACCEPT, YYABORT, or cleanup of the start symbol.
> 
> > I'm not complaining that
> > yydestruct is called in this manner, only that the documentation hasn't
> > been updated to indicate this behavior, and provide relevant examples!
> 
> Even though there aren't many examples, I find the 2.1a documentation to 
> be fairly clear.  Does it help?
> 
> Joel