On 2005-04-27, at 01:55:22 +0200, Hans Aberg wrote: > At 00:09 +0200 2005/04/27, Marcus Holland-Moritz wrote: > >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... > > Why don't you define YYMAXDEPTH to the MAXINT or something? Then you > can only get overflow by memory running out.
Ok, let me try to explain my point once more. I don't need any sort of "workaround". There's no problem that I need to solve quickly. The current solution I have is fine, I just like to replace it with something better if possible. %destructor looks like it has the ability to be this "something better", but IMO it currently isn't as good as it could be (i.e. it is worse than my solution with regard to potential memory leaks arising from parser stack overflow). I am aware of the fact that if the parser stack blows up, there's no way to parse the code. Fine. But at least in my application that isn't much different from a syntax error, since it's just reported to the user as an error. He can try to fix his code, and run the parser again. And again. And again. This doesn't mean he shuts down the application in between. For example, one of my applications has an editor where you can enter code and press a button to "compile" the code, which will be carried out by the module using the bison parser. The user can hit "compile" a million times. Even though it is extremely unlikely that he writes code that blows the stack, I don't want the module to leak memory, especially if it's possible to avoid it. I think #define'ing YYMAXDEPTH to MAXINT (or any other XXL number) isn't a good idea. I know that no sane code requires the parser stack to be as large as 1000 items. So with YYMAXDEPTH = 10000 I'm clearly on the safe side. And I prefer to have an error at a well-defined boundary rather than some part of the application running out of "real" memory when passed illegal input. My point is that I think bison's %destructor behaviour could be extended to all error cases where a cleanup of the stack is possible, and I think the parser stack overflow is such an error case. Unless someone can tell me why it is not possible or why it should not be done. > > > 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. > > There I do not see exactly what you need. Perhaps Paul can help. To quote the bison docs: "Basically, during error recovery, embarrassing symbols already pushed on the stack, and embarrassing tokens coming from the rest of the file are thrown away until the parser falls on its feet. If these symbols convey heap based information, this memory is lost. While this behavior is tolerable for batch parsers, such as in compilers, it is unacceptable for parsers that can possibility "never end" such as shells, or implementations of communication protocols. The %destructor directive allows for the definition of code that is called when a symbol is thrown away." So, %destructor _is_ what I need. It's bison's built-in facility to avoid memory leaks. All I'd like to see is that the existing functionality is extended to the parser stack overflow case. Marcus _______________________________________________ Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
