Re: bison bug.

[Hans Aberg]

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