Re: Updating from bison 1.24 to 2.4.1

On Fri, 23 Jul 2010 05:08:13 -0700 (PDT), Tuggi
<soeren.zimmermann@sef.de> wrote:


>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)
jump labels.




>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
same input.
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
>problems. -John]


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.


George
[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 comp.compilers page.
Search the comp.compilers archives again.