Hi Hans, thanks for the quick response!
On 2005-04-26, at 23:46:10 +0200, Hans Aberg wrote: > Again, this is probably a question for Paul to answer, who wrote the > current C-parser. I thought that the C-parser was dynamic, except > when free store runs out, in which case one is toast anyway. What Yes, it is dynamic. Up to YYMAXDEPTH. Besides, I don't think that anyone will ever get the parser to exhaust its stack. But my test suite checks the "parser overflow" error and that test will leak memory if any stray objects aren't cleaned up. Which is bad for the memory leak checker... My current keep-unreferenced-objects-in-lists method handles the overflow without any leaks, and I'd like to keep that behaviour if I switch to using %destructor. > version of Bison are you using? Is it Bison 2.0? If you have disabled Yes, Bison 2.0. > parser stack dynamic reallocation, and gets stack overflow, how do > you intend to recover. I mean, then the parser cannot handle the > input semantics properly anyway. Sure. I don't want to recover. I just don't want to leak memory. As I mentioned, the parser is embedded in a Perl module, and the module shouldn't leak memory as the code using the module may run for long periods of time. Marcus > At 22:39 +0200 2005/04/26, Marcus Holland-Moritz wrote: > >Hi, > > > >I've been using bison for the C parser in one of my perl modules for a > >couple of years now. (http://search.cpan.org/~mhx/Convert-Binary-C/) > > > >I recently noticed the %destructor feature and it looks as it would solve > >a problem that has long been on my todo list. Right now I'm collecting > >all objects that I don't reference otherwise in various lists so I can > >free them when the parser exits (when it exits normally, the lists are > >usually empty). However, maintaining these lists is time-consuming (both > >in programming time and execution time). > > > >I've now rewritten my parser to make use of %destructor, and it works > >fine generally. The only case where it doesn't work is when a parser > >stack overflow is detected. I can see from the generated parser code > >that a parser stack overflow error bypasses yydestruct(). > > > >My question: Is there a reason why the %destructor code isn't called > >upon parser stack overflow? > > > >I don't see a reason, because when the stack overflow is detected, > >the whole stack is still valid and even the items about to be pushed > >on the stack are valid and known to the parser. So it should at least > >be possible to do a correct cleanup of the parser stack. > > > >Thanks, > >Marcus > > > >-- > >One of the most overlooked advantages to computers is... If they do > >foul up, there's no law against whacking them around a little. > > -- Joe Martin > > > > > >_______________________________________________ > >Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison _______________________________________________ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison