[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: %destructor documentation not quite right...
From: |
Steve Murphy |
Subject: |
Re: %destructor documentation not quite right... |
Date: |
Sat, 22 Apr 2006 08:20:11 -0600 |
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