Marcus Holland-Moritz <[EMAIL PROTECTED]> writes:
> Does the test part of my patch make any sense?
Yes, I think so. Thanks. I checked everything in.
___
Help-bison@gnu.org http://lists.gnu.org/mailman/listinfo/help-bison
on 2005-04-28, at 22:46:21 -0700, Paul Eggert wrote:
> Marcus Holland-Moritz <[EMAIL PROTECTED]> writes:
>
> > When the parser detects a stack overflow, it should call
> > the cleanup actions defined via %destructor for all symbols
> > on the stack (and the symbol causing the overflow) before
> >
On 2005-05-01, at 06:28:46 -0700, Paul Eggert wrote:
> Thanks for the patch, but I suspect the code patch isn't quite general
> enough, since a similar problem occurs if the user invokes YYACCEPT or
> YYABORT. How about this patch instead?
Yes, that's a lot better. My patch rather only fixed the
Thanks for the patch, but I suspect the code patch isn't quite general
enough, since a similar problem occurs if the user invokes YYACCEPT or
YYABORT. How about this patch instead?
2005-05-01 Paul Eggert <[EMAIL PROTECTED]>
* data/yacc.c (yyerrlab): Move the code that destroys the stac
Marcus Holland-Moritz <[EMAIL PROTECTED]> writes:
> When the parser detects a stack overflow, it should call
> the cleanup actions defined via %destructor for all symbols
> on the stack (and the symbol causing the overflow) before
> it returns.
Yes, that sounds right. Can you write and test a pa
At 22:47 +0200 2005/04/28, Marcus Holland-Moritz wrote:
> So if you get a stack overflow error, what do you want to happen?
Clearly, the parser must be taken down. You want it then to done so
that stack cleanup takes place. Right? Possibly, the same cleanup
actions as those in %destructor shoul
On 2005-04-27, at 23:19:43 +0200, Hans Aberg wrote:
> At 21:20 +0200 2005/04/27, Marcus Holland-Moritz wrote:
> >%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 potent
At 21:20 +0200 2005/04/27, Marcus Holland-Moritz wrote:
%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).
The intent
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 wa
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
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.
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
version of Bison are you using? Is it Bison 2.0? If you have disabled
parser stack dynamic rea
12 matches
Mail list logo
