bug-bison
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MAXTABLE & Serious issues with bison 1.30


From: Tim Van Holder
Subject: MAXTABLE & Serious issues with bison 1.30
Date: 03 Jan 2002 08:53:43 +0100

We're in the process of stripping down a third-party yacc file (i.e.
removing all actions) so we can use the grammar to do our own
processing.
But bison complained that the maximum table size was exceeded.
Recompiling bison (1.28) with a greater MAXTABLE (64K-1 instead of
32K-1) helped, and the grammar compiled fine.  Of course, it would be a
LOT nicer if bison dynamically increased the table size; depending on
any hard-coded limit is sub-optimal.

Then I thought I might as well upgrade to bison 1.30, so I downloaded
the source, increased MAXTABLE again, and compiled.  Now bison received
a segmentation fault if -d was used.  Debugging suggested there was a
buffer overrun somewhere (once the crash was in malloc(), the other time
in free()).  In addition to that, the .output file generated by bison
1.30 had issues (no newlines in the grammar list, and no 'reduce' blocks
in the states (so no easy S/R debugging possible)).

So I thought I'd try CVS bison (knowing how Akim likes to add all kinds
of cool stuff to CVS versions of tools :-) ).  While the latter two
problems were fixed, the crash still existed.  In addition, the CVS
repository had two other (fairly major) issues. First off, it requires a
pre-release version of autoconf; this is unacceptable, as bison has no
relation to autoconf.  I don't mind if bison _uses_ a prerelease
version, but then the generated files should also be in CVS.  Secondly,
a similar, but much worse situation exists in the src directory, as
parse-skel.y can ONLY be processed by CVS bison.  This is a MAJOR
chicken-and-egg problem.  It's easy enough to work around this by
commenting out the unsupported % directives and manually running bison,
but this sort of thing is never acceptable.

</rant>
There.  I thinks that's all for now :-)
Well, there is one more thing: what about also renaming YYSTYPE when a
name-prefix is specified?  Since it's unconditionally included in every
tab.h file, it's impossible to include more than one such file (well, at
least not without surrounding the #include with "#define/#undef YYSTYPE
SomethingElse").

PS 1: I'm planning to update the Dutch translations to be more palatable
and up to date; do I send in a patch to you, or should I go through
li.org?  Do I need FSF papers to update a .po file?

PS 2: I'm not on the list, so please keep me in the CC:.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]