|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)|
|From:||George Neuner <email@example.com>|
|Date:||Mon, 26 Jul 2010 12:18:04 -0400|
|Organization:||A noiseless patient Spider|
|Posted-Date:||26 Jul 2010 13:03:40 EDT|
On Fri, 23 Jul 2010 05:08:13 -0700 (PDT), Tuggi
>we were still using an old version of bison (v 1.24).
>... 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.
You're using an old version that either was compiled with 16-bit
integers or is targeted to a 16-bit C compiler. The parser state
machine code can't be generated because Bison has run out of (legal)
>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".
>I also want to mention that generating the c-file causes 1 shift/
>reduce and 2 reduce/reduce conflicts.
Reduce/Reduce is a FATAL error in an LR parser. It means that your
grammar is ambiguous and there are 2 or more rules which apply to the
The latest versions of Bison have *experimental* support for GLR
parsing, which can deal with such ambiguity. However, if you are not
an expert, you should stay away from GLR.
Shift/Reduce is a warning which means that your grammar has a
construct which is potentially confusing. The typical cause of this
is a nested IF-THEN-ELSE construct. If your grammar allows nested
conditionals then you probably don't need to worry about this.
Since Bison found Reduce/Reduce conflicts, it would have returned an
error code so that make (or whatever build system you use) knew to
stop the build. [Nope. See below. -John]
>[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
Possibly ... but it may be related to the Reduce/Reduce conflicts. As
it stands, the parser is hopelessly confused. He needs to fix those
conflicts first before looking for other problems.
[As the prior message noted, bison produces a parser even if there are
reduce/reduce errors, by using the rule that appears first in the source
file. I agree that fixing the conflicts would be a good idea. -John]
Return to the
Search the comp.compilers archives again.