Re: MAXTABLE & Serious issues with bison 1.30

[Tim Van Holder]

On Thu, 2002-01-03 at 10:01, Akim Demaille wrote:
> >>>>> "Tim" == Tim Van Holder <address@hidden> writes:

> Happy new year.

Best wishes to you and yours as well.

> This is something upon which we will all agree.  First of all, what is
> the exact limit you're hitting?

I didn't expirment to find out the actual size used; doubling the
existing limit seemed acceptable (in fact, I think the existing limit
was only chosen for memory conservation reasons, as a lower limit is
used for the real-mode DOS version; those issues hardly matter these
days (especially since we're talking about less than 1MB)).

> There are several dependencies over
> short, some of which being unsigned short.  That would be easy to
> overcome.  The other limitations are much more delicate and require a
> walk through the code.

It seemed to me that MAXTABLE was unrelated to short; it's only used as
an array size (cfr. output.c), and as an upper bound that's checked
against.  All cases I saw used an int as indexer into that, so this
seems unrelated to the short-related constants.  bison 1.28 is running
just fine with an increased table size.


> Tim> Then I thought I might as well upgrade to bison 1.30, so I
> Tim> downloaded the source, increased MAXTABLE again, and compiled.
> 
> 1.30 is dead broken.

I noticed.

> Give a try to the betas on alpha.gnu.org/gnu/bison.

I tried the 30a - 30e tags in CVS, as well as HEAD; all exhibited the
crash.

> Tim> While the latter two problems were fixed, the crash still
> Tim> existed.  
> 
> I am interested in getting the grammar, if that's possible.

Sure. I'm told it is GPL'd, so I can distribute it.  I've attached it to
this message.  It's not the cleanest grammar by a long shot (1060+681
conflicts, most of which were probably caused by stripping the actions),
but that shouldn't matter to bison.

> Tim> In addition, the CVS repository had two other (fairly major)
> Tim> issues. First off, it requires a pre-release version of autoconf;
> Tim> this is unacceptable, as bison has no relation to autoconf.  
> 
> Yes, it has: me.

Well yes - but I meant bison as a program, not the bison project. 
automake, autoconf and libtool ARE related as programs, so it is
understandable that the development version of one uses the development
version of the other.  With bison that link is not that clear at all.

> Tim> I don't mind if bison _uses_ a prerelease version, but then the
> Tim> generated files should also be in CVS.  
> 
> That is the case of the 1.30 branch.  As far as the CVS experimental
> version goes, it's OK to use it.  And to be honest, I'm fine with
> releasing Bison using a beta of Autoconf too.

I'm reasonably fine with that too, as it's distributed with configure nd
the other generated files.
My gripe was mainly that CVS HEAD did not include those files.

> In other words, I'm not really sensitive to this being an issue.  We
> need help and feedback and experience on Autoconf to release it.  GNU
> M4, GNU Bison, GNU a2ps have all served to this end, and still do.

Agreed.

> Tim> Secondly, a similar, but much worse situation exists in the src
> Tim> directory, as parse-skel.y can ONLY be processed by CVS bison.
> 
> Wrong, it can be processed by the other branch, or, if you prefer,
> 1.31.

Then the configure script for the trunk should check for a compatible
version of bison and complain if it's not found.

i4gl.y
Description: Text document