Re: bison bug.

[James Harris]

The problem is that nitems is larger then SHRT_MAX, while this variable is
a int, others which in some cases can hold the same value are shorts.  
The root of the problem is mixing shorts and ints.  The 'solution' of
adding an assert to force a int to hold no more then a short seems no only
illogical but a waste.  If I want a ridiculously large parser thats my
business, I think the tool can be made to solve the case it should.  I'm
working on getting some data on memory usage, and parser size in hopes we
can make an informed decision.

-- James Harris

On Fri, 28 Dec 2001, Hans Aberg wrote:

> At 21:42 -0800 2001/12/27, James Harris wrote:
> >A quick update on my bug hunt. It looks like there is an overflow in at
> >least one of the many shorts Corbett uses. Adding "#define short int" into
> >system.h seems to be a down and dirty fix.  Im going to setup a watches on
> >each short and should have a better fix soon.
> ...
> >> | I belive a some internal variable is to
> >> | small. As you can see the number 256 rules is rather telling. 255 is
> >> | acceptable, 256 produces the bug.
> 
> The C94 standard has a header limits.h with a SHRT_MIN/SHRT_MAX value at
> least -/+ 32767. So if 256 causes an overflow in your shorts (no pun
> intended), your compiler does not conform to STD C.
> 
> Further, token numbers start at 257 (in #define <token_name> <number>).
> 
> However, reader.c, packsymbols(), has the lines:
>   max_user_token_number = 256;
>   last_user_token_number = 256;
> 
> Perhaps it has something with that to do: If I change these lines to:
>   max_user_token_number = 256;
>   last_user_token_number = 255;
> I instead get the
> Error   : Bison Compiler-Compiler
> foo.y line 1283   tokens error and foo_0 both assigned number 256
> 
> I don't see any reasons for Bison to limit the number of tokens to 256: The
> tokens are stored on a doubly linked list.
> 
>   Hans Aberg
> 
>