|Updating from bison 1.24 to 2.4.1 email@example.com (Tuggi) (2010-07-23)|
|Re: Updating from bison 1.24 to 2.4.1 firstname.lastname@example.org (Hans Aberg) (2010-07-25)|
|Re: Updating from bison 1.24 to 2.4.1 email@example.com (George Neuner) (2010-07-26)|
|Re: Updating from bison 1.24 to 2.4.1 firstname.lastname@example.org (Gene) (2010-07-27)|
|Re: Updating from bison 1.24 to 2.4.1 email@example.com (George Neuner) (2010-07-28)|
|Re: Updating from bison 1.24 to 2.4.1 firstname.lastname@example.org (Joel E. Denny) (2010-07-29)|
|Date:||Fri, 23 Jul 2010 05:08:13 -0700 (PDT)|
|Posted-Date:||24 Jul 2010 15:45:14 EDT|
I've got a problem when trying to update bison from version 1.24 to
2.4.1. Here it goes:
We're working on quite a large project. One of the main parts of our
application is a parser implementing a proprietary scripting language.
For this purpose we're using flex/bison. Our application is a Windows
application, developed with the Borland Developer Studio 2006 in C++.
As the project development started several years ago, we were still
using an old version of bison (v 1.24).
Until now our scripting language has been extended a lot and so did
the flex and bison definition files increase. But as we tried to add
another rule to the bison definition file lately, bison denied work.
The error message was
"limit of 32767 exceeded, too many gotos".
Well, I'm no bison expert so I don't know what internal limit is
meant. We had 163 tokens and 173 rules defined. When trying to add
rule 174, the error occurred.
That is why I downloaded and installed the latest version of bison for
Windows (v 2.4.1).
When I generate a c-file from our bison definiton file (*.y) with the
old version of bison (1.24) and use this c-file within my application,
all works fine and the application runs as usual.
Then I use the new bison version (2.4.1) with the same *.y-file.
Running bison and compling my application with the generated c-file
works with no errors. But running the new built application causes
trouble: It crashes! Calling yyparse() now leads to an
EAccessViolation-exception. Calling yyparse() twice even terminates
the application with an "Abnormal program termination".
Is there something like a compatibility mode when using bison? Or any
other things to regard?
I also want to mention that generating the c-file causes 1 shift/
reduce and 2 reduce/reduce conflicts. I didn't find the reason yet,
because I'm engaged in the flex/bison code for a short time. Despite
of these warnings the c-file generated with the old bision (1.24)
As this project is very vital to us, I'm quite desperated by now and
do appreciate any kind of help.
Thanks in advance
[I suggested that this problem usually means that there are pointer bugs in
user code that happened not to crash until the new version of bison moved
the data around. Debug them the same way one debugs any other pointer
Return to the
Search the comp.compilers archives again.